¿Por qué Common Lisp no es el lenguaje de programación más popular?
El misticismo duradero de Common Lisp contrasta con su adopción limitada: muchos programadores elogian su sistema de macros, el REPL interactivo, el manejo de condiciones y la estabilidad a largo plazo, pero encuentran la sintaxis, el uso intensivo de listas enlazadas y la semántica de múltiples espacios de nombres difíciles de leer y enseñar. Los comentaristas argumentan que las herramientas y bibliotecas fragmentadas, la falta de una única implementación o ecosistema de paquetes dominante, y la ausencia de un gran patrocinador corporativo han impedido que CL se convierta en una opción predeterminada en la industria, especialmente en comparación con lenguajes derivados de C, Python o JavaScript. Existe amplio acuerdo en que, aunque Lisp sigue siendo una caja de herramientas potente y flexible para pequeños equipos expertos y dominios nicho, su flexibilidad, su estilo cargado de DSL y su carga histórica lo convierten en una mala opción para grandes organizaciones de ingeniería intercambiables y para la incorporación generalista.
Efectos históricos y de red
- Los primeros Lisps necesitaban hardware costoso; para cuando las máquinas se pusieron al día y CL se estandarizó, C y Unix ya habían ganado popularidad.
- El invierno de la IA acabó con los proveedores comerciales de Lisp; hoy no hay un respaldo grande y visible análogo a Sun/Oracle para Java o a los grandes usuarios de Python.
- Se considera que la popularidad depende más de los efectos de red y del patrocinio corporativo que del mérito técnico.
Ecosistema, herramientas y despliegue
- Se describe la gestión de paquetes como fragmentada y débil; existen varias herramientas en competencia y poca convergencia hacia “una obvia” para cosas como serialización o async.
- Algunos sostienen que el ecosistema es más amplio y estable de lo que creen quienes están fuera (Quicklisp, ayudantes de FFI, muchas bibliotecas), pero es más difícil de descubrir y carece de soporte al estilo de Stack Overflow.
- Se elogian los REPL y los flujos de trabajo basados en imágenes (conditions, restarts, depuración remota, desarrollo incremental), pero se dice que la experiencia del REPL por CLI en implementaciones libres es áspera sin integración con el editor.
- El tamaño binario y el despliegue son objeto de debate: SBCL puede generar binarios autónomos, pero son relativamente grandes; las implementaciones comerciales lo hacen mejor.
Diseño del lenguaje: poder frente a accesibilidad
- Quienes lo defienden destacan macros, diseño basado en expresiones, despacho múltiple (CLOS), el sistema de condiciones/restarts, tipado incremental, FFI y la estabilidad a largo plazo del estándar.
- Quienes lo critican ven CL como un “cajón de sastre” con carga histórica (espacio de nombres separado para funciones, listas centradas en cons, modelo arcaico de pathnames).
- Algunos sostienen que CL “hizo fáciles las cosas difíciles pero difíciles las cosas fáciles”: las estructuras de datos cotidianas (vectores, maps) y la ergonomía de las listas se sienten peores que en lenguajes modernos.
Listas, paréntesis y sintaxis
- Muchos comentaristas dicen que la principal barrera es la sintaxis: el uso intensivo de paréntesis y los idioms centrados en listas enlazadas se sienten ajenos y difíciles de leer.
- Otros responden que, con editores estructurales, indentación y familiaridad, los paréntesis “desaparecen”; el problema real es que el estilo idiomático de procesamiento de listas resulta ajeno.
- Hay debate sobre las listas enlazadas en sí: algunos las consideran obsoletas frente a arrays y maps; otros dicen que son ideales para el código exploratorio, pero que deben sustituirse por rendimiento.
Macros, DSL y mantenibilidad
- Las macros y las reader macros se ven a la vez como la característica estrella de CL y como su maldición.
- Los entusiastas valoran el “código que escribe código” y las abstracciones específicas de dominio; los detractores sostienen que cada base de código acaba siendo su propio dialecto, aumentando la carga cognitiva y dificultando el mantenimiento en equipos grandes.
- Se hacen comparaciones con las extensiones de Haskell y los “subsets” de C++: la flexibilidad sin convenciones fuertes puede producir código ilegible o altamente idiosincrático.
Corporación, comunidad y cultura
- Varios argumentan que CL encaja mejor con equipos pequeños y expertos que con grandes organizaciones que quieren desarrolladores intercambiables, convenciones estrictas y contratación fácil.
- Algunos ven la comunidad de CL como individualista, lenta para estandarizar o aceptar parches, y sin estructuras cohesivas de conferencias o fundaciones.
- Otros informan de una experiencia profesional agradable con CL y discuten que sea inmantenible o especialmente problemática para principiantes.
Comparaciones con otros lenguajes
- Clojure se cita como un “Lisp moderno” que aprovecha el ecosistema de Java y las estructuras de datos inmutables.
- Julia se señala como influido por Lisp, con macros y despacho múltiple, pero todavía joven y abordando problemas como el tamaño binario y los restarts.
- Rust, Go, Python y JavaScript se comparan con frecuencia: se benefician de ecosistemas sólidos, herramientas y respaldo corporativo, incluso cuando imponen más restricciones o complejidad que CL.