Barrapunto

Yo actualmente uso Groovy [codehaus.org], un lenguaje dinámico que pretende ser una especie de capa sobre java. Este nos permite con una sistexis muy parecida a Java obtener muchas ventajas asociadas a este tipo de lenguaje, ademas de acceso nativo a cualquier api de Java y de ejecutarse sobre la VM. Perl lo uso por que le tengo mucho cariño y por que para administracion o para "Quick & Dirty" no hay nada que se le parezca

En la entrevista sólo se comenta de pasada la estrecha relación que liga a estos lenguajes dinámicos con el software libre. A nadie se le puede escapar que Perl, Python, PHP etc. son projectos de SL y que en la gran mayoría de los casos son usados para desarrollar programas también libres o de código abierto.

¿Es esto casual? Desde luego que no. Las grandes compañías de software prefieren entregar sus programas compilados para que sea difícil saber lo que hacen o modificarlos. Y sí, ya sé que Sun apoya el desarollo de versiones de Python y otros lenguajes que corren sobre la JVM, pero lo hacen más bien para permitir el desarrolo de programitas rápidos de juguete y no como plataforma para aplicaciones serias.

¿Qué significa esto? ¿Es una desventaja para los lenguajes dinámicos? ¿Es una ventaja para el sofware libre? ¿Ambas cosas a la vez?

Los lenguajes dinámicos retrasan a etapas posteriores del desarrollo el encuentro de posibles bugs.

Con lenguajes rígidamente tipados como C# podemos comprobar que el programa es léxica, sintáctica y semánticamente correcto con sólo compilar. Lo único que se puede escapar son errores de ejecución.

Los lenguajes tipados muestran todos los errores en tiempo de ejecución, lo que ralentiza el desarrollo muchísimo.

Yo estoy migrando todos mis proyectos de lenguajes dinámicos a lenguajes estáticos.

Saludos.

del VBScript y del JavaScript, LOS MAS IMPORANTES!!!!

----introduccion-----
Los lenguajes de scripting son geniales para escribir mucho codigo rapidamente. Pero esto se suele conseguir acompañado de tipado suave.

De modo que puedes hacer algo como esto:

normalID = ID;

El problema es que hay muchas formas de escribir eso:

normalId = ID; //Caso A
normalID = (int) ID; //Caso B
normalID = (string) ID; //Caso B
identificadores[normalID] = ID;//Caso C.1
identificadores[normalId] = ID;//Caso C.2

En el caso A, muchos lenguajes no te diran nada, simplemente crearan una nueva variable. Y la correcta normalID no sera nunca actualizada con el valor correcto. Es una muerte silenciosa y crea un bug dificil de encontrar.
El caso B es aun mas sutil. Porque no es lo mismo "0378" que "378". El primero es una cadena, el segundo un entero. Nuestro lenguaje hara uno de los dos. ¿Adivinas cual?. De nuevo se nos pueden colar errores dificiles de encontrar.
El caso C supone que tenemos un array de valores. Podemos meter el valor en el lugar incorrecto, y un lenguaje de estos tampoco se quejara. Otro bug dificil de encontrar.

Pero no todo esta perdido. Muchos lenguajes como PHP o Perl permiten escribir codigo que sea estricto y que genere warnings gordos ante codigo que probablemente sea un error, obligandonos a escribir un codigo mas seguro.
----/introduccion-----

----el estado de los lenguajes de script-----

Yo veo que los lenguajes de script de hoy en dia han conseguido cosas muy interesantes que los compiladores casi consiguieron pero no lograron del todo. Muchos lenguajes de scripting hacen facil escribir codigo multiplataforma. No hay que tener unos conocimientos especiales.

Lenguajes como Perl, PHP y Ruby tienen repositorios de modulos y obtenerlos esta integrado en el lenguaje (CPAN, pear y gems), ademas de las librerias originales que continen casi todo lo que alguien pueda necesitar. Y una prueba de la madurez de los lenguajes de scripting es que sus librerias estan escritas en ellos mismos. Los modulos de perl estan escritos en perl, y los modulos de php en php, etc..

Otra caracteristica de los lenguajes de scripting muy interesante es su modernidad. El que mas y el que menos implementa features de lenguajes serios, por ejemplo la Reflection, OOP con singletons, etc.. (toda clase de sintax sugar). Cosas que no veras en muchos lenguajes clasicos y que pueden ser muy utiles. ( se me ocurre que programar una *Unit aprovechandose de la feature de reflection debe ser casi trivial y quedar automagico )

Pero bueno, ¿Como diria harry el sucio?. Harry diria algo asi como que un lenguaje de script es un lenguaje de script, da igual si se baña con muchisimo jabon, si se friega la piel con piedra pomez o se echa lejia por encima. Incluso aunque se queme la piel con cloro. Un lenguaje de scripting sigue siendo un lenguaje de scripting.

----/el estado de los lenguajes de script-----

Aquí [jclement.ca] teneis otro artículo interesante sobre los lenguajes de "scripting", titulado "Solving the Software Crisis with Scripting Languages" de Jeff Clement.

Lo encuentro interesante, para añadir al debate ;)

Mira, yo entiendo que prefieran llamarlos lenguajes dinámicos. Almenos a mi siempre me ha costao entender PHP, Phyton, Rubi, etc. como scripting. A lo mejor es una visión un poco diferente, pero para mi el scripting es hacer "guiones" para que lo interprete la linea de comandos, y no me gusta alejarme de la shell... Yo veo el scripting como un seudo programa que sirve para ciertas cosas, pero no para cualquier cosa. Mas aún, yo diría que si quieres hacer un programa no debes utilizar scripting...

Me parece más acertado catalogarlos como lenguajes dinámicos, ya que no me recuerdan tanto a las "guarredidas" que se hacen en un script. Si te sales de la shell entonces no es un script, es otra cosa... No se si se me entiende el concepto, pero básicamente es que un script debe poder correr en una shell pelada. Discutiendo estas cosas con la peña he llegado a una definición para este tipo de scripting, sweet scripting... Es que es tan tienno no tener que dejar la dulce shell ;) Pero si quieren llamarlos lenguajes dinámicos a mi ya me sirve, sólo es por diferenciar conceptos...

Programa pequeño, tipado dinámico. Programa grande, tipado estático.

En general, es tan fácil como eso.

Un poco más arriba se hacía mención a la performancia de los programas implementados con lenguajes dinámicos. Y alguien se ha referido a aplicaciones en el campo científico (entre otros) como ejemplo de uno dentro del cual no tienen cabida.

Pero todos conocemos la vieja regla de que el 10% del código de un programa se ejecuta el 90% de su tiempo de proceso y que, puestos a optimizar, el bucle interno es más importante que el externo.

Mi experiencia de programación con lenguajes dinámicos se reduce a Python, R y Java. Y, especialmente los dos primeros, los he usado con éxito para el desarrollo de de algoritmos muy exigentes en términos de carga de la CPU. Desde mi punto de vista, la lentitud de ejecución percibida por muchos programadores avezados en el uso de, por ejemplo, C, es una consecuencia de la inercia: están acostumbrados a codificar de una manera que, efectivamente, redunda en tiempos de ejecución exasperantes.

C es un lenguaje que, exagerando un poco, es pura gramática y carece de un vocabulario. Un programador de C enseguida echa mano de sus construcciones gramaticales para, por ejemplo, construir un bucle; sabe, por ejemplo, que para sumar los números de un array no tiene más remedio que utilizar en algún sitio un for(i=0...; en cambio, el desarrollador de una aplicación en un lenguaje dinámico cuenta con un abanico amplio de funciones --muchas veces implementadas nativamente en C, por lo que la pérdida de rendimiento es marginal-- sustitutivas de bucles y gracias a las cuales puede optimizar ese 10% del código que el programa va a estar recorriendo más frecuentemente.

Además, una de las características más de agradecer de los lenguajes dinámicos es la facilidad que ofrece (generalmente) su diseño para integrar en ellos rutinas compiladas.

Por ello, creo que ambos tipos de lenguajes de programación están abocados a coexistir y complementarse íntimamente. Los unos son más fáciles de desarrollar y depurar, generan código más legible y son ideales para crear el esqueleto lógico de las aplicaciones. Los otros, brindan la potencia de la que carecen los primeros cuando lo que importa es la velocidad de ejecución bruta.

Y, por supuesto, no aprecio, como otros, lugar para la controversia; sólo descubro nuevos horizontes de elección.

Pues eso, yo creo que la mayor carencias de estas magnificas soluciones, son que sus entornos de desarrollo, son austeros comparados con otros.

Conoceis soluciones o Ide's tipo delphi, VB, etc,,, para PHP o Python?

Perl o Python son tan lenguajes de programación como C o Java. El que opine lo contrario es un miserable. ... con esos argumentos que das que de por si solos son irrebatibles todos te tenemos que darte la razón. Por otra parte el que crea en la evolucion es un hijo-puta-socialista-miserable-marica-comunista-ma son-PPero-de-mierda(tm) y encima amante del SL. y punto.

Que tal un poco de rigor al dar opiniones, que eto parece el patio del colegio.