La tragedia de Lisp

El lenguaje de programación universal consideró: ¿por qué Lisp no surgió como alternativa superior a un montón de tecnologías?

En este artículo voy a considerar el asunto con algo más de profundidad, pues aunque creo que la razón fundamental es el mercadeo, también hablé de que Lisp tenía algunas debilidades que podrían haberse subsanado con solo el 10% de lo invertido en Java.

Aún suponiendo que Java no fue inventado, habría poca probabilidad de que Lisp se convirtiera en un lenguaje muy popular, fundamentalmente por dos razones:

• Su naturaleza extensible
• La comunidad detrás del lenguaje

La naturaleza extensible de Lisp, promovió la creación de múltiples dialectos del lenguaje a un punto que hoy Lisp no es solo un lenguaje, sino una familia de lenguajes que comparten la sintáxis y algo de la semántica del primer Lisp. Uno de los miembros notables de esta familia es Scheme, que cambió algunas reglas semánticas de Lisp, y fue rápidamente estandarizado por la IEEE, mientras la estandarización de Lisp en el ANSI marchaba a paso de tortuga coja.

La comunidad de Lisp, siendo mayormente académica gusta de las soluciones completas y elegantes, así que tarda mucho en ponerse de acuerdo en cual es la solución ideal para un problema, eso fue una de las causas fundamentales de la lentitud en la definición del Common Lisp (CL).

Hoy en día tenemos que las principales implementaciones de Lisp son ANSI Common Lisp (CL), que tiene un sistema avanzado de orientación a objetos llamado CLOS y Scheme que es un Lisp sencillo, pero con interesantes capacidades de crecer fácilmente en el área de la concurrencia, por la implementación de continuaciones. Ambos pueden ser compilados nativamente y a código intermedio o incluso interpretados directamente.

Scheme, tiene a su vez varios dialectos que suelen ser muy compatibles entre sí, la comunidad detrás de Scheme (ingenieros) es mucho más pragmática que la de CL (académicos), y se han mantenido extendiendo el lenguaje con regularidad mediante los "Revisedⁿ Report on the Algorithmic Language Scheme" o (RⁿRS), así que las diversas implementaciones de Scheme se declaran compatibles con R⁴RS, R⁵RS, etc.

Lo cierto es que Lisp sufrió y todavía sufre de una aparente fragmentación, similar a la de Unix para los años 80, que permitió que un sistema operativo con una única implementación y semántica ganara mercado rápidamente, este fenómeno es similar con Lisp.

Sin embargo la fragmentación es aparente, podríamos considerar que CL, Scheme, QI, etc. son lenguajes diferentes, que comparten una sintaxis similar y referirnos a Lisp como familia únicamente, pero no es así, por alguna razón los vemos como un lenguaje fragmentado, de la misma manera se podría decir que C está fragmentado en C, C++, Java, ECMAscript y hasta Perl.

Me gustaría investigar un poco más, las causas que hacen que los Lisps sean considerados como dialectos, aún cuando lenguajes como QI son tan diferentes a CL, mientras los lenguajes que comparten mucho de la sintaxis y la semántica de C son considerados lenguajes diferentes.

Si a principio de los 90 Common Lisp hubiera sido una versión unificada de Lisp, habría sido mucho más fácil identificarlo como un lenguaje para la web, no solo para programar en ella, sino para definirla en base Lisp.

Si Sun, en vez de inventar un lenguaje nuevo, hubiera tomado CL como base y lo hubiera llamado Java, hoy Java sería igual de popular, pero eligieron mantenerse en lo comercial, eligieron mantener no solo la sintaxis de C sino las características de C y C++.

Algunos aseguran que Sun tenía miedo de que el lenguaje fuera demasiado avanzado (¿academico?), y puede ser, porque GJ (un java con programación genérica), apareció hace como 15 años, y no fue hasta hace muy poco que Java adquirío solo algunas características de GJ, y todavía discuten si agregan construcciones funcionales al lenguaje, fundamentalmente porque viene un autobús que no se quieren perder y Microsoft ya lo está abordando.

Sin embargo, Lisp sigue allí latente y evolucionando, esperando por la bala de plata que lo ponga a competir con los grandes, claro que ahora lenguajes como SML, OCaml, Erlang, Haskell y Clean derivados de los conceptos de programación funcional de Lisp, se van a montar en el mismo autobus que está a punto de arrancar y que dejará atrás a muchos de los lenguajes imperativos que conocemos hoy en dia (incluso a Java, si Sun no se pone las pilas).

La historia del autobus, se las debo, porque quiero escribirla con más calma.