Debería funcionar
Divulgación y, sobretodo, divagación sobre computación, mayormente práctico.

Desde hace más de un siglo, existen unos lenguajes creados artificialmente con el fin de ayudar a sus creadores en aquellos problemas repetitivos que les han ido surgiendo en sus vidas, y para conseguir resolverlos de forma más rápida.

De esta manera, se empezaron diseñando máquinas que conseguían tejer más deprisa que a mano, otras que entendían el dibujo, a base de perforaciones, de una tarjeta, con el fin de generar distintas presiones en un conjunto de válvulas neumáticas y hacer que funcionara un piano por sí solo... y así se llegó a la fase en la que a un buen hombre, llamado Von Neuman, se le ocurrió que no debería ser necesario modificar los conectores de las máquinas que realizaban las operaciones cada vez que éstas cambiaban a otro conjunto de operaciones a realizar, si no que eso debía ser transparente en base a un programa (a base de instrucciones) que se le pasara. Curiosamente, dicho diseño de las máquinas (o hardware) no ha variado demasiado.

En cambio, los programas (o software) sí que han cambiado mucho. O mejor dicho, los lenguajes en los que se escriben, hasta el punto de existir, hoy en día, miles de ellos, creados por empresas (por iniciativa propia), universidades (igualmente) o por expertos comunicados a través de Internet (aunque patrocinados, algunos de ellos, por empresas y/o universidades).

Al principio, dichos lenguajes eran muy cercanos al funcionamiento de las máquinas (mover dato del primer registro al segundo), probablemente por inercia de lo que pocos años antes se realizaba (mover el conector de la primera ranura a la segunda). A continuación, se crearon lenguajes que juntaban algunas de estas instrucciones en una sola (sumar y almacenar), hasta llegar a los llamados lenguajes de alto nivel, entre los que se hayan (y basan) los lenguajes de scripting.

Salvando varios años de esta historia (una pena), nos plantamos en algunos de los lenguajes más usados actualmente, y porqué.

C, por ejemplo, es el lenguaje de programación con el que se han escrito la mayoría de lenguajes de scripting existentes (por lo menos, en sus versiones originales, y más usadas), por no mencionar programas más importantes, como el corazón de millones de ordenadores (el núcleo de varios sistemas operativos). Éste es un lenguaje bastante complicado (porque puede requerir saber interioridades de las máquinas), pero extremadamente potente en manos de un experto.

De aquí, se puede extraer la primera crítica hacia dichos lenguajes de scripting: en cuanto a rendimiento, estos lenguajes son lentos, ya que al estar escritos en C, nunca podrían correr más rápido que aquellos escritos en C. Sin embargo, no se debería olvidar que C fue inventado para poder escribir UNIX de forma que fuera multiplataforma, con el fin de evitar la necesidad de reescribir todo el código para cada tipo de máquina. Es decir, C se pensó para la programación de sistemas, y puede que la balanza quede desequilibrada si ponemos sus ventajas e inconvenientes para el desarrollo de aplicaciones, u otro tipo de código.

Por otro lado, está Java, lenguaje nacido en los ochenta con el fin de facilitar el desarrollo de programas enfocados a la televisión interactiva, que por aquellos años Sun Microsystems pensaba que sería el futuro inmediato. ¡mooonc!. Pronto cambió su objetivo a la naciente Web, y hasta hoy (gracias al apoyo inicial de Netscape). Los programas en este lenguaje, tras ser compilados, generan un código que es ejecutado por máquinas virtuales, de forma que no es necesario recompilarlos para ser ejecutados en múltiples plataformas diferentes.

Y por último, está Bash, intérprete de comandos de los sistemas GNU basado en SH que, apoyado en pequeños programas como sed, tr, ... y por otros lenguajes como awk, se utiliza en programas de administración de dichos sistemas. El problema es que este lenguaje limita su uso a los sabores GNU de UNIX, y obliga a utilizar múltiples procesos para una misma tarea, algo que puede resultar lento en situaciones más complicadas. Además, awk no permitía mantener abierto más de un fichero.

Volviendo al primer párrafo de esta divagación, y cuando parecía que las herramientas a nuestro alcance eran suficientes para generar programas enfocados a operaciones de sistemas, de aplicaciones o administrativas, varios inconformistas crearon Perl, Python, Ruby, PHP... y el más nuevo: Groovy.

Estos lenguajes de scripting son difíciles de catalogar porque, todos ellos, pueden ser compilados o interpretados, descolocando a aquellos que, como yo, pensaban que esa era la característica diferenciadora, y que les mantenían a distintos niveles.

Las ideas principales que pululan por ahí sobre los lenguajes de scripting son:

• Conseguir que sea (más) fácil programar
• Crear un código legible
• Reducir las líneas de código necesarios para una misma tarea
• Tipado dinámico (no hace falta declarar las variables)
• Recolectores de basura (encargados de gestionar la memoria del programa y otros asuntos del que algún día espero escribir)
• En algunos casos, son diseñados para un dominio específico (como la Web)
• Crear un conjunto numeroso de bibliotecas (o módulos) bien probados y fiables que permitan no reinventar la rueda
• Independientes de la máquina en la que se ejecuten (multiplataforma)

Tampoco podemos olvidar la motivación de sus inventores. Por ejemplo, Perl nació de la mano de un administrador de sistemas y redes que por aquel entonces (1987) trabajaba en un centro de investigación (JPL-NASA) en el que necesitaba realizar informes de los registros (logs) generados por otros programas. Por lo menos, esto es lo que inicialmente trascendió al populacho :-D. En ese caso, probablemente podría haberse utilizado SH, CSH, Bash, o el intérprete de comandos que usaran los sistemas que administraba. Pero el problema, a grandes rasgos, era la XOR obligada cuando quería utilizar funcionalidades de C y de *SH (o usaba uno, o usaba el otro). Además, es posible que entre dichas máquinas hubiesen algunas con Windows, el cual, por aquella época (y por ésta O:-D), no disponía de un intérprete de comandos adecuado, y le obligaría a reescribir sus programas para otros lenguajes (Basic o el que fuere), poco preparados para su objetivo.

Otro caso muy interesante es el de Python, lenguaje liberado al público 5 años después que Perl. La primera versión fue desarrollada en unas navidades aburridas, según comentaba su creador, y se basaba en otro lenguaje llamado ABC, en el que por aquel entonces trabajaba. Su motivación principal era acercar el mundo de la creación de programas a personas que no fueran programadoras. De hecho, en ocasiones puede parecer una poesía matemática, por su mezcla de conjunciones (if, while), nombres (variables), verbos (is, is not), identación, álgebra de boole, etc.

Ambos creadores, probablemente, aprendieron del infierno de otros lenguajes de scripting como APL, muy concisos pero complicados de ser leídos, y en general de todos los lenguajes de programación creados anteriormente. Un ejemplo simplón es el de separar distintos ámbitos (o entornos) en base a palabras (begin, end), llaves, o identación, según la legibilidad que se piensa se conseguirá. Pascal es un ejemplo de verborrea en comparación con C y sucedáneos.

Tradicionalmente, se ha pensado que estos lenguajes de scripting eran un reemplazo de los intérpretes de comandos, o de otras herramientas de preparación de programas para ser configurados e instalados. Así, hay desarrolladores que prefieren usar Ruby en lugar de ANT (menor limitación en el uso de condicionales, ...), o programas administrativos que han sido reescritos en Perl o Python (como el administrador de paquetes de Red Hat, o el informador de bugs de Debian), pero sobretodo Python. Estos usos pueden confundir a los recién llegados a estos lenguajes que, viniendo de la filosofía anterior de usar cada lenguaje para un dominio específico, no consiguen entender que cada uno de ellos pueda ser utilizado para (casi) cualquier intención.

Por ejemplo, Perl se utiliza fundamentalmente como simulación avanzada de los anteriores programas en Bash, pero también tiene un amplio uso en algoritmia, bioinformática, catalogación, ... y Python es muy utilizado como enlace entre programas tradicionalmente utilizados a golpe de ratón (o lapiz óptico), como Gimp, 3d Studio, etc., y programas propios, añadiendo ese plus de potencia a nuestros programas.

Aunque en la década de los 90 existía la misma emoción por el uso de Java que la que hay ahora con estos lenguajes de scripting (¡¡son el futuro!!), siempre quedan algunas dudas al buscar equivalencias con lo que ya se tiene, para intentar una migración casi transparente (y ganando la productividad que tanto se vende con estos lenguajes). Tras esta emoción previa surgen preguntas sobre cómo gestionar proyectos con un gran número de desarrolladores en estos lenguajes (o si siquiera existe ese gran número de desarrolladores que sean expertos en estos lenguajes), si existen los mismos patrones de diseño que con los actuales lenguajes, si se consigue integrar el código tan bien o mejor que con lo actual... y la verdad es que no he conseguido leer apenas sobre estos asuntos (de lo que deduzco que es el momento de innovar y lanzarse a la piscina... y ver qué pasa).

En cuanto a los patrones de diseño, es algo que, en mi opinión, va a haber que replanteárselo, porque para conseguir soluciones funcionales y muy contrastadas a lo largo de los años, como el patrón Singleton, es necesario hacer trucos sucios para replicarlo en estos lenguajes.

En cuanto a la integración, es una cuestión complicada de responder. En principio, opino que puede llegar a ser incluso más fácil de conseguir (tras un buen diseño, claro). El problema creo que está entre el teclado y la silla: crear buenas pruebas unitarias. Es decir, producir muchos más conjuntos de pruebas puesto que la libertad de valores manejados por las variables es infinitamente mayor. Con esto me refiero a la diferencia que supone el tipado estático (propio de C, Java, ...) y el dinámico (Perl, Python, Ruby...). En el primero, es necesario declarar las variables, y el compilador da fé de su buen uso a lo largo de todo el programa (asignaciones, pasos de parámetros, etc.). Por contra, el tipado dinámico permite no declarar variables hasta su primer uso, que podrá ir cambiado de tipo a lo largo del programa.

Por ejemplo, se puede tener un array de enteros y cadenas de caracteres mezclados, y cada uno heredará los métodos propios de su condición (substr, etc.). Éste uso es correcto en estos lenguajes de scripting, y por tanto está en manos de los programadores preparar una buena batería de pruebas para eliminar (reducir) funcionamientos no esperados.

Otra molestia muy relacionada con lo anterior es la escasa existencia de buenos IDEs (entornos de desarrollo) para estos lenguajes. Sí son capaces de conseguir integrar depuradores, coloreadores de sintáxis, ... pero complicado encontrar refactorizadores de código, autocompletadores de métodos de un objeto, etc. en gran parte debido a ese carácter dinámico.

En definitiva, los lenguajes de scripting son muy potentes (incluso aquellos específicos de un dominio, que lo serán para ese dominio), pero en ese gran crecimiento que están teniendo actualmente, se encuentran unas barreras quizás demasiado altas para pasar, en el mundo de la empresa, de ser utilizados en la generación de prototipos a cuestiones mayores, pero que han impulsado una nueva generación de lenguajes artificiales, que esta nueva generación sí que no creo que quede en una moda. De hecho, lenguajes como C# ya están incorporando tipado dinámico...

Desde bien pronto, el creador de Ruby ya dejó claro que su filosofía era crear un lenguaje fácil de usar, no enfocado en el rendimiento del mismo, básicamente porque no le parecía lo más importante dado que otras cuestiones en el ámbito de su uso (la Web) producirían cuellos de botella (como las comunicaciones de red), y siempre quedaría utilizar otros lenguajes en caso de priorizar dicho rendimiento.

Para mí, lo más importante es que todos estos lenguajes de scripting (famosos) son software libre, algo que ha impulsado la comunidad de usuarios y desarrolladores de módulos alrededor de ellos, y que sin ello no creo que hubiesen llegado al nivel en el que hoy están.

Recomiendo encarecidamente pasarse por sus sitios webs oficiales, donde se podrá encontrar abundante información sobre ellos, a todos los niveles.