Lisp, Ruby y patrones

Tras una estimulante conversación con Juan, acerca de lo divino y de lo humano y en particular de los lenguajes dinámicos y los funcionales, y más en concreto sobre mi favorito (Ruby) y su favorito (Lisp), vuelvo una vez más a sumergirme en unos cuantos artículos sobre programación funcional y Lisp, los que me ha pasado él, y alguno que tenía en la recámara (incluso alguno que ya había leído). Me gusta leer sobre programación funcional (y en general sobre cualquier tecnología que parezca interesante y diferente a lo que uso normalmente), no tanto para usarla (de momento sigo pensando que hoy por hoy, y para el tipo de cosas que yo hago en mi día a día, Ruby y Rails siguen siendo la opción mejor y más pragmática) sino para, por un lado, enterarme cuando esa afirmación deje de ser cierta, y, por otro, copiar las cosas buenas y usarlas; en particular me gusta mucho la filosofía de “no side effects” y eso muchas veces es más una cuestión de estilo que de lenguaje.

Pues bien, en uno de esos que ya había leído, el casi clásico y recomendabilísimo (aunque sólo fuera por el título) Revenge of the Nerds de Paul Graham, me encuentro, casi al final, algo que me pasó por alto en mi anterior lectura, y que me recordó muchísimo a otra conversación que tuve con Luismi hace apenas unos días, sobre el uso (o más bien desuso) de patrones en Ruby, y que resume creo que a la perfección nuestra conclusión.

Tras comentar una algo pedante pero graciosa décima regla de Greenspun (“Any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp.”), se pone un poco más serio y explica lo que quiere decir:

If you try to solve a hard problem, the question is not whether you will use a powerful enough language, but whether you will (a) use a powerful language, (b) write a de facto interpreter for one, or (c) yourself become a human compiler for one. (…)

This practice is not only common, but institutionalized. For example, in the OO world you hear a good deal about “patterns”. I wonder if these patterns are not sometimes evidence of case (c), the human compiler, at work. When I see patterns in my programs, I consider it a sign of trouble. The shape of a program should reflect only the problem it needs to solve. Any other regularity in the code is a sign, to me at least, that I’m using abstractions that aren’t powerful enough— often that I’m generating by hand the expansions of some macro that I need to write.

Dudo que se pueda añadir algo más, salvo que con Ruby sucede prácticamente lo mismo =;-)

servido por porras 1 comentario compártelo