Adoptando Common Lisp en el mundo moderno

La relevancia moderna de Common Lisp se compara con Clojure y los lenguajes basados en la JVM, con muchos elogiando los nuevos recolectores de basura de SBCL, las opciones de despliegue de bibliotecas y proyectos como Coalton, mientras lamentan la débil integración con editores, la documentación desigual y las herramientas GUI anticuadas. Los comentaristas debaten si el modelo alojado de Clojure, centrado en Java, con tipado dinámico y acceso al ecosistema compensa su sobrecarga de JVM, sus trazas de pila complicadas y su dependencia del conocimiento de la plataforma subyacente. El hilo también aborda afirmaciones ambientales sobre lenguajes más “verdes”, los compromisos entre IDEs Lisp comerciales potentes y herramientas de código abierto como Emacs+SLIME/SLY, y cuestiones más amplias sobre rendimiento, depuración y la viabilidad a largo plazo de los runtimes alojados frente a los autocontenidos.

Desarrollos del ecosistema de Common Lisp

  • SBCL está evolucionando activamente: nuevos recolectores de basura paralelos y concurrentes están en beta, con el objetivo de reducir pausas y aprovechar CPUs multinúcleo.
  • SBCL-LIBRARIAN mejora el despliegue como bibliotecas compartidas compatibles con C para interoperabilidad con C/Python sin RPC.
  • Coalton añade una capa tipada estáticamente, similar a Haskell, Lisp‑1, con clases de tipos e inferencia; las secuencias persistentes (árboles RRB) proporcionan seqs al estilo de Clojure.
  • Los usuarios, no los comités, están impulsando muchas de estas innovaciones.

Common Lisp frente a Clojure y a los Lisp alojados en la JVM

  • Muchos ven a Clojure como el Lisp “moderno” más corriente, pero otros sostienen que Emacs Lisp puede tener más usuarios.
  • Objeciones a Clojure: bloat y huella de memoria de la JVM, tipado dinámico, bibliotecas y trazas de pila centradas en Java, dependencia del conocimiento del host y fragilidad del lenguaje alojado.
  • Algunos aprecian las estructuras de datos inmutables de Clojure, STM, spec e interoperabilidad con Java/.NET/JS, pero ven el ecosistema Java como un pacto fáustico.
  • Alternativas mencionadas: Clojure CLR/Script/ERL, Basilisp (Clojure sobre Python), Armed Bear CL en la JVM y Lisps sobre BEAM.

Herramientas, editores y depuradores

  • Existe soporte de editores para Common Lisp más allá de Emacs (VS Code, JetBrains, Atom/Pulsar, Lem, Geany, etc.), pero a menudo se considera incompleto o inestable.
  • Algunos ven Emacs + SLIME/SLY como extremadamente potente; otros lo encuentran chapucero en comparación con IDE comerciales pulidos (Allegro, LispWorks) o depuradores generalistas (Visual Studio, Smalltalk).
  • Hay desacuerdo sobre si el estilo guiado por REPL de CL reduce la necesidad de depuradores GUI “modernos”.

Documentación y curva de aprendizaje

  • Varios sostienen que el mayor obstáculo para la adopción es la documentación de bibliotecas deficiente e inconsistente, no los editores.
  • La introspección de CL (DESCRIBE, ir al código fuente) compensa en parte, pero crea una cultura de leer código en lugar de escribir documentación.

Rendimiento, eficiencia y argumentos “verdes”

  • Algunos afirman que Common Lisp (especialmente SBCL) puede ser más ligero y tan rápido o más que los lenguajes de la JVM, especialmente en inicio y código intensivo en CPU, y por tanto más “verde”.
  • Otros cuestionan el marco ambiental, argumentando que los ahorros energéticos en centros de datos al cambiar de Clojure a CL probablemente sean minúsculos, y que también importan los costes de tiempo humano.
  • Se debaten benchmarks y el rendimiento de JVM frente a CL frente a C/C++, sin un consenso claro.

GUIs y aplicaciones de escritorio

  • Los Common Lisps libres carecen de una historia de GUI multiplataforma y generalizada.
  • Ideas y proyectos mencionados: envoltorios al estilo Electron/Tauri alrededor de aplicaciones web en CL, McCLIM (potente pero inmaduro y centrado en X11), CLOG, Ceramic (en gran medida sin mantenimiento) y Nyxt como un entorno de CL en un navegador.