¿Por qué apuntar a Common Lisp para la generación de código?
Una entrada de blog que sostiene que los modelos de lenguaje grandes encajan especialmente bien con Common Lisp —presentándolo como un lenguaje “para hackers de élite”— desata un debate tanto sobre ese marco elitista como sobre las afirmaciones técnicas. Los comentaristas evalúan las fortalezas de Lisp para la programación asistida por IA, como la homoiconicidad, las macros potentes, el código denso y los flujos de trabajo interactivos con REPL, frente a desventajas prácticas como bibliotecas escasas, peculiaridades de SBCL y la tendencia de los modelos a desbalancear paréntesis o mezclar dialectos de Lisp. Muchos concluyen que, aunque Lisp puede ser una excelente opción para flujos de trabajo con LLM guiados por expertos, la elección del lenguaje está impulsada en última instancia más por las habilidades del equipo, la madurez del ecosistema y consideraciones económicas que por cualquier estatus “elitista” inherente.
Elitismo, cultura y autodescripción
- A muchos les resulta incómodo o repelente llamar “élite” a Lisp o a sus usuarios, y suelen preferir que el trabajo hable por sí mismo.
- Otros defienden el reconocimiento explícito de la experiencia y rechazan la “democratización” que, según ellos, devalúa la habilidad.
- Varios señalan una subcultura de larga data de los “smug Lisp weenie” y bromean con que los entusiastas de Lisp mantienen una autoimagen de nicho pese a su escaso uso generalizado.
- Normas culturales como la humildad (por ejemplo, la “Law of Jante”) influyen en cómo reacciona la gente ante un lenguaje autoensalzador.
¿Es Lisp realmente para élites?
- Algunos usuarios veteranos de Lisp sostienen que Lisp es más fácil de lo que su reputación sugiere, apto para personas sin formación en programación e incluso para niños, y que el mito de lo “aterrador y elitista” perjudica su adopción.
- Otros reconocen el lastre de Common Lisp (acumulaciones históricas, familias de funciones complejas, empaquetado y construcción de ejecutables) y dicen que otros Lisps pueden ser más accesibles.
Common Lisp + LLMs: pros, contras y herramientas
- Varios informan que los modelos “frontier” modernos generan Common Lisp o Clojure decentes; los modelos más antiguos o pequeños suelen mezclar dialectos y frecuentemente desbalancean paréntesis.
- Las herramientas (utilidades de reparación de paréntesis, editores estructurales) y los trucos de prompting (limitar la profundidad de anidamiento, salida estructurada) se usan mucho para corregir los paréntesis.
- Algunos sostienen que la sintaxis pequeña y regular de Lisp, el código denso y los flujos de trabajo impulsados por REPL encajan bien con las LLM, permitiendo bucles de retroalimentación cerrados y un uso eficiente de tokens.
- Otros replican que las LLM favorecen la verbosidad y la repetición, tienen dificultades con el anidamiento profundo y con tokens de baja información como los paréntesis, y rara vez inventan buenas macros o abstracciones sin guía humana.
Argumentos económicos y prácticos a favor de CL
- Un usuario importante de CL sostiene que, con LLM, la elección del lenguaje importa más por el rendimiento y la densidad del código que por la corrección básica o la seguridad.
- El código denso y de alto rendimiento en CL podría reducir tanto los costes de tokens como los de infraestructura; sin embargo, algunos comentaristas dudan de que las LLM produzcan de forma natural ese tipo de código denso y rico en macros.
Elección de lenguaje, seguridad y ecosistema
- Hay desacuerdo sobre si las LLM pueden producir código en C con tanta seguridad como Go/Rust/CL; algunos citan errores sutiles de memoria y vulnerabilidades recientes generadas por LLM.
- Go es elogiado como propicio para el “vibe coding” debido a que ofrece una sola manera obvia de hacer las cosas y una biblioteca estándar sólida, mientras que el ecosistema de CL se describe como comparativamente escaso.
- Algunos enfatizan que el desarrollo es una actividad de equipo y que las herramientas deben adaptarse al equipo, no a las preferencias individuales de lenguaje.
Meta: benchmarks, DSL y alternativas
- Varios sugieren que los benchmarks actuales de código ignoran fortalezas específicas de cada lenguaje, como los flujos de trabajo con REPL, y que deberían mejorarse.
- Algunos usan DSL parecidos a Lisp (por ejemplo, Hy) dentro de stacks convencionales (como Django) y reportan un buen soporte de LLM.
- Una minoría quiere explícitamente mantener Common Lisp “libre de LLM” porque todavía les aporta alegría.