Por qué Common Lisp es ahora el mejor lenguaje de programación

Artículo original ↗ Discusión en Hacker News ↗

Common Lisp se presenta aquí como un lenguaje ideal para la “era de los LLM” por su desarrollo vivo basado en imágenes, su depurador potente y su sistema de macros para construir lenguajes específicos de dominio concisos que podrían reducir el uso de tokens y acelerar la programación asistida por agentes. Muchos participantes discrepan, argumentando que los tipos estáticos fuertes (Rust, OCaml, F#, Go, etc.), las herramientas maduras y los ecosistemas amplios importan más para el desarrollo asistido por IA, y que la recarga en caliente y la depuración interactiva también existen en otras plataformas. La conclusión general es que no ha surgido un único lenguaje “mejor” para programar con LLM: la elección del lenguaje sigue dependiendo del dominio, la arquitectura y la mantenibilidad humana, aunque la gente reporta resultados prometedores con varios Lisps, Python y otros ecosistemas.

Depurador, condiciones y recarga en caliente

  • Muchos comentarios se centran en el sistema de condiciones de Common Lisp: los errores no capturados pueden llevar a un depurador interactivo sin desenrollar la pila, lo que permite cambiar valores o recompilar funciones y luego reanudar la ejecución.
  • Los defensores dicen que esto acorta el ciclo de depuración, funciona incluso con código compilado y es especialmente potente en sistemas de larga duración o en desarrollo impulsado por REPL.
  • Los críticos sostienen que esto es arriesgado en producción (cambios “en vivo” sin seguimiento, posibles trampas) y que, en la práctica, los servidores CL suelen simplemente registrar backtraces y hacer fallar la solicitud, como otros lenguajes.
  • Varios señalan que otros ecosistemas (.NET, Java, Dart, JavaScript, Smalltalk) también admiten depuración remota, edit-and-continue o recarga en caliente, así que CL no es único en este aspecto.

Macros, DSL y eficiencia de tokens para LLMs

  • Las voces pro-Lisp enfatizan las macros para construir DSL que codifican opiniones del dominio y reducen enormemente las bases de código, lo que podría reducir el uso de tokens de LLM y mejorar la legibilidad.
  • Otros responden que:
    • Los DSL añaden su propia sobrecarga de aprendizaje y mantenimiento, y pueden convertirse fácilmente en una macro-helly opaca.
    • Los LLM no necesitan DSL para ser productivos, y quizá prefieran lenguajes convencionales con abundantes datos de entrenamiento y convenciones.
    • Los hosts estáticos y tipados (Rust, OCaml, Lean) podrían ser mejores plataformas para DSL gracias a garantías más fuertes.
  • Hay un amplio debate sobre si la brevedad y la “plasticidad del lenguaje” realmente dominan el rendimiento de los LLM frente a la arquitectura, los tipos y el ecosistema.

Desarrollo basado en imágenes y agentes

  • Varios informan buenos resultados al conectar agentes LLM a Lisps vivos (Common Lisp, Clojure, imágenes al estilo Smalltalk, Janet): los agentes se conectan a REPL, recargan código, ejecutan pruebas e introspeccionan el estado dentro de un sistema en ejecución.
  • Este flujo de trabajo se describe como rápido y como “tecnología alienígena”, pero también como nicho y en tensión con el despliegue desechable basado en contenedores; algunos encuentran patrones similares viables en Python/iPython o Node con autoreload.

Tipado estático vs dinámico

  • Un bando sostiene que los tipos estáticos fuertes (Rust, OCaml, Haskell, Scala, F#) son especialmente valiosos para los LLM: actúan como especificaciones ejecutables, dan retroalimentación precisa del compilador, restringen el espacio de búsqueda y ayudan a grandes equipos a refactorizar.
  • Otros señalan:
    • Common Lisp está fuertemente tipado en tiempo de ejecución y puede soportar sistemas estáticos (por ejemplo, estilo Coalton) encima.
    • Los ecosistemas dinámicos pueden usar especificaciones en tiempo de ejecución, predicados y pruebas generativas para capturar invariantes ricos que muchos sistemas estáticos convencionales no pueden expresar fácilmente.
  • No surge consenso; ambos bandos citan experiencia personal con LLM que favorece su paradigma preferido.

Rendimiento, bibliotecas y seguridad

  • El rendimiento de CL (especialmente SBCL) se describe como competitivo con otros lenguajes gestionados, aunque bastante por detrás de C/C++ optimizado en benchmarks.
  • Preocupaciones del ecosistema: menos bibliotecas, y menos auditadas; soporte ausente o más débil para piezas “fundacionales” como SDK de nube, drivers de BD, ASN.1, etc.
  • Algunos argumentan que los LLM pueden portar o reimplementar barato bibliotecas faltantes; otros se preocupan por redescubrir particularidades, la falta de revisión de seguridad y el coste en tokens de las reescrituras “desde cero”.

Reclamos de “mejor lenguaje” y escepticismo sobre el artículo

  • Muchos rechazan la noción de un único lenguaje “mejor”, invocando órdenes parciales y compensaciones multidimensionales; la elección del lenguaje se ve como dependiente del dominio y de la organización.
  • Varios comentaristas dicen que el artículo exagera la singularidad de CL y minimiza características similares en otros ecosistemas; algunos lo llaman contenido impulsado por fans o incluso “slop” generado por LLM.
  • Hay discusión meta sobre cómo ahora cada comunidad argumenta que su favorito pre-LLM (Python, Rust, Go, F#, Elixir, etc.) es “el lenguaje agéntico perfecto”, con justificaciones en gran medida simétricas.

Miscelánea

  • Discusión sobre ERP/DSL: la gente señala que los dominios ERP difieren mucho entre industrias; la semántica es la parte difícil, así que los DSL e incluso los LLM no producen mágicamente lenguajes ERP reutilizables y universales.
  • Algunos marcan el sitio enlazado como sospechoso por tener un div invisible con enlaces pornográficos, lo que hace que los filtros corporativos lo clasifiquen como “material para adultos”.