ZingZang.org

Bufff....

/me babea

Encontré esta guía rápida de introducción ayer, y aguanté hasta hoy para seguirla.

Resumiendo, se crea una pequeña aplicación de llevar tareas pendientes (muy chorra, sí) desde cero con Ruby on Rails. La verdad es que es impresionante. Yo modifiqué un poco el ejemplo y fui escribiendo una pequeña aplicación (también muy chorra) para gestionar parches a programas. La idea es tener una página simple donde poder dar de alta los parches que uno escribe, para qué aplicación son, si están aplicados o no en la versión original, a partir de qué versión, etc.

Ahora me queda jugar más con él, y seguir desarrollando la aplicación.... y probar Nitro un día de éstos, claro O:-)

Últimamente han estado hablando en la lista de Ruby sobre si de verdad los lenguajes de tipado dinámico sólo son apropiados para pequeños proyectos. Yo nunca lo he tenido claro, porque he visto algunos proyectos razonablemente grandes escritos en lenguajes interpretados dinámicos... así que nunca he tenido claro si era una percepción «conservadora» o si tenía algo de verdad.

Algunos de los comentarios decían que lo más importante era hacer baterías de pruebas, y que un compilador rara vez iba a ayudarte en los fallos semánticos, que son los más difíciles de detectar.... y otros decían que el mayor problema de los tipados dinámicos no era trabajar en un proyecto desde cero, sino recibir un proyecto de otras personas, y encontrarte páginas y páginas de métodos y funciones que, al no tener información de tipo en los parámetros, no sabes muy bien cómo usar/interpretar.

Y la verdad es que sigo sin tenerlo claro O:-)

El comentario de los que pensaban que los lenguajes de tipado dinámico pueden tener un mantenimiento más pesado tienen razón (al menos en parte), pero quiero pensar que las convenciones y cultura de los lenguajes hacen eso relativamente fácil. Vamos, al menos lo suficiente como para que compense a la lentitud de desarrollo y a la dificultad de reorganización de los lenguajes de tipado estático.

¿Qué opinan?

Me parece extremadamente sorprendente, y más aún viniendo de donde vienen, el comportamiento de los generadores de Python:

        def fib():
            a, b = 0, 1
            while 1:
                yield b
                a, b = b, a+b

Lo que hace eso de ahí arriba NO es definir una función, sino un generador. Es decir, que al hacer:

        cosa = fib()

No se quedará en un bucle infinito, sino que en cosa quedará un iterador, que se puede recorrer con valor = cosa.next() y eso. Cuando lo leí estaba convencido de que el cosa = fib() se quedaría en un bucle infinito, pero no.

Toda la confusión viene por usar la palabra clave def también para los iteradores, simplemente distinguiendo a éstos de las funciones, por el hecho de que los primeros tienen la palabra («mágica», para mi gusto) yield dentro.

Incluso parte de la comunidad Python (lógico, por otra parte, no van a estar todos de acuerdo) está de acuerdo conmigo y lo expresa muy bien en el texto del propio PEP, en una parte donde hablan de añadir la palabra reservada gen, por ejemplo, en vez de usar def (ver abajo, en el apartado «BDFL Pronouncements»):

In this respect they're radically different from non-generator functions, acting more like a constructor than a function, so reusing "def" is at best confusing. A "yield" statement buried in the body is not enough warning that the semantics are so different.

Vamos, que Setepo lo explicó muy bien en
http://www.hispalinux.es/~setepo/blog/tonterias/yieldunico

SCNR :-P

Hace meses ya que la gente de dpkg (la herramienta de gestión de paquetes de Debian, una de las más avanzadas del mundo) quería añadir baterías de pruebas para mejorar la calidad y sobre todo para asegurarla ante los cambios.

Pues bien, el menda hizo un bocetillo/experimento de infraestructura de pruebas hace tiempo, y ahora parece que se va a reactivar un poco el desarrollo (sobre todo, desde que salga definitivamente Sarge). Los experimentos iniciales (por si a alguien le interesa probar y tal) están en mi página de Debian.

Todo se basa en Dejagnu, un entorno de pruebas que usa Tcl (¡ajjj!) como lenguaje de integración.

Y, por cierto, hablando de dpkg, parece que Scott James Remnant (el más activo en el desarrollo de dpkg ahora mismo, diría yo) está trabajando en una rama propia mantenida en el magnítico sistema de gestión de cambios Arch...

Chacho, chacho, chacho, qué escándalo...

Sé que no soy precisamente la persona más objetiva para decir esto, pero están saliendo un montón de entornos de programación web interesantes para Ruby.

La mayoría de ellos están inspirados en los típicos entornos de Java, como Struts y Tapestry (según he podido leer, porque realmente no los conozco bien), pero hay otros que intentan otras vías, como CGIs con esteroides y eso.

El que parece más usado con diferencia es Ruby on Rails, aunque últimamente Nitro me está llamando también la atención. Si tuviera tiempo, o si en el trabajo surgiera la oportunidad.... jorjorjor...

También hay algunas aplicaciones web interesantes, como Instiki (el Wiki sin tercer paso de instalación), nosecuántos otros Wikis más, y el nuevo sistema de foros que están escribiendo en Rails los integrantes de dos o tres proyectos que antes iban por separado...