Me conseguí
un artículo que confirma algunas de las cosas que siempre digo sobre el desarrollo de software, en particular, insisto en que Java es una gran pérdida de tiempo y dinero para la sociedad, sobre todo cuando desde hace mucho tiempo hay mejores lenguajes y plataformas.
En el artículo se cuenta la historia de éxitos que se lograron utilizando Lisp en el JPL de la NASA, como el
reparar una nave espacial que se encontraba a más de 100 millones de millas de la tierra, debido justamente a las características del lenguaje y su plataforma de ejecución.
Hoy en día tal vez suene raro eso de usar
Lisp, debido a la percepción (tal vez debería decir el prejuicio) de que es anticuado, o incluso arcaico, sin embargo después de jugar un rato con
SBCL uno se puede dar cuenta de lo fácil y dinámico que es el ambiente, es como trabajar con Perl o Python. Lisp resuta ser tan divertido que incluso estoy usando Emacs (sorry Vim, el ambiente
SLIME de Emacs es la merma para trabajar con Lisp).
Siendo
SBCL un ambiente tan dinámico como
Perl o
Python, con
uno de los mejores y más flexibles sistemas de OOP, que sirvió de inspiración para desarrollar
Moose en Perl, extraña que pueda competir con Java en poder de procesamiento, pero consumiendo mucho menos memoria que este. Además con una semántica bien definida y conocida, producto de: su fundamento matemático, un
estándar formal, y una tradición que tiene más de 5 décadas.
Un benchmark demuestra que aún después de casi dos décadas de echarle dinero al pote de Java, todavía ambientes como SBCL (mantenidos únicamente por una comunidad de voluntarios), son más eficientes, y eso no es una casualidad, es una característica de su diseño.
Sin embargo, preferimos un producto corporativo, porque nos vendieron sus grandes innovaciones, tales como: el manejo automático de la memoria y la portabilidad, características que Lisp tiene desde finales de los años 50, unos 30 años antes que Java.
Ahora el daño está hecho, se ha invertido una gran cantidad de tiempo, esfuerzo y dinero en Java, hay que ver que se hace con el monstruo, no puedo estar más de acuerdo con el autor del
artículo sobre Lisp en el JPL:
Es muy frustrante ver que todo esto ocurra. Mi trabajo hoy (trabajando en la verificación y validación del software) es resolver problemas que se remontan directamente a la uso de lenguajes puramente imperativos con semántica mal definida como C y C++ (la situación es un poco mejor con Java, pero no mucho). Pero, por supuesto, la solución obvia -- utilizar lenguajes no imperativos con semántica bien definida, como Lisp -- no es una opción. Ni siquiera puedo decir la palabra Lisp sin afianzar mi reputación como un loco que piensa que Lisp es la respuesta a todo. Así que decidí mantener la boca cerrada (la mayor parte del tiempo) y ver con impotencia cómo se gastan millones de dólares de los impuestos.
Por eso es que no escribo demasiado
sobre el tema, sin embargo de vez en cuando es bueno revivir la discusión a ver si alguien escucha y se puede corregir el error.
Este es un tiempo interesante, la
tecnología funcional se ha reconocido como la única vía para explotar la potencia de las nuevas arquitectura del hardware, por ello Microsoft promueve F#, mientras aparecen lenguajes como Clojure que funcionan sobre la JVM, y es pertinente avisar que hay lenguajes como
Haskell, que son mejores que F#, y otros como Lisp y
Scheme que son mejores que Cojure.
Para todos los que fans del software corporativo: que dirían si les vendiera el lenguaje BigLisp con las siguientes características:
- sano
- seguro
- con manejo automático de la memoria
- alto rendimiento
- bajo consumo de recursos
cuyos programas pueden ejecutarse sin modificación en cualquier plataforma Unix y Windows que tenga un compilador de C, en la máquina virtual de Java, en el ambiente .NET y también en Mono, pero con la capacidad de explotar lo mejor de cada una de estas plataformas y utilizar sus librerías y servicios directamente a cambio de pérdida de la portabilidad.
¿ Me lo comprarían ?
Y si les dijera que lo que aprendan utilizando ese lenguaje, les servirá para toda una familia de lenguajes similares, que van desde herramientas grandes y complejas como los
verificadores de teoremas, hasta librerías de scripting de menos de 300kB (no es un error son 300 kilobytes) que podrían simplificar y extender con facilidad programas de C y C++.
¿ Me lo comprarían ?
Seguro que no, incluso habría gente que me diría que eso es vaporware o ciencia ficción, sin embargo llega una empresa como Sun vendiendo la basura de Java y todo el mundo lo compra sin ni siquiera navegar por internet a ver si existe algo mejor.
En realidad BigLisp no existe, sin embargo hay una versión de
Scheme llamada
Bigloo que tiene casi todas las características que antes mencioné pero que casi nadie usa, porque quien lo hace no es una corporación multinacional, sino un centro de investigación que además hace otro lenguaje espectacular llamado
OCaml, que tampoco tiene demasiados usuarios.
Por otra parte los conocimientos de Lisp adquiridos al aprender Scheme, serán útiles para aprender a utilizar herramientas como
ACL2 o para extender los programas C, como lo hicieron con
Gimp al agregarle
ScriptFu, que no es mas que
TinyScheme embebido.
Aún así estoy seguro de que muy poca gente me va a comprar eso, mientras no este en las noticias, y nada de eso va a ser noticia porque es casi tan viejo como las primeras computadoras, así que no es noticia, como tampoco es noticia la tecnología de la electricidad, aunque sin ella estaríamos todavía en el siglo XVII.
Mi esperanza es que se comiencen a usar plataformas modernas, que tienen ventajas comparables a las de Lisp, con comunidades que están llegando al punto de masa crítica, y cuyas plataformas avanzan cada vez más rápido, como por ejemplo:
Haskell.
