Por qué elegí Common Lisp

Adiós, Clojure

• Usé Clojure durante unos 7 años, pero ya no me resultaba satisfactorio por el problema del "inicio lento" en las apps CLI
• Existían proyectos como babashka, pero incluso con native-image de GraalVM era difícil resolver el problema del inicio lento
• El "inicio rápido de un ejecutable independiente" se volvió un requisito indispensable, y concluí que Clojure no podía cumplirlo

Buscando un nuevo Lisp

• Investigué varios lenguajes para encontrar un nuevo Lisp. Buscaba uno que pudiera resolver los problemas que había tenido en proyectos anteriores
• No tenía "requisitos explícitos", pero terminé ordenando criterios como estos
  • Debía poder generar "ejecutables independientes que arrancaran rápido" con una toolchain razonable (para resolver mi principal queja con Clojure)
  • Como no podía usar Emacs, tenía que poder usarse desde Vim
  • El soporte para Windows y Mac era indispensable; no bastaba con soportar solo sistemas Linux/POSIX
  • Sería ideal que tuviera posibilidades de integración con otros lenguajes de comunidades grandes, como Clojure y Java
  • La velocidad en runtime debía ser suficientemente rápida (preferiblemente al nivel de Clojure o superior)
  • El soporte de multithreading debía ser sólido y, si era posible, sin algo como el GIL (Global Interpreter Lock)
  • Una comunidad fuerte era indispensable
  • Debía tener un ecosistema rico y, como mínimo, contar con estas librerías
    • Parsing y serialización de JSON
    • Soporte para Sqlite3
    • Librería para requests HTTP
    • Soporte para estructuras de datos funcionales como en Clojure (aunque esto era menos importante)
• Lenguajes que investigué
  • Scheme: entre r6rs y r7rs, la comunidad estaba dividida por el problema de los estándares, lo que no me atrajo; además, su ecosistema era pequeño y no cubría mis necesidades
  • Racket: lo había usado en mi época de estudiante, pero me parecía lento y pesado en runtime, así que no lo preferí
  • Common Lisp: lo encontré en lisp-lang.org. Su comunidad y la documentación me impresionaron, así que decidí probarlo

Magic Happens Here

• Omito la historia completa de mi recorrido aprendiendo Common Lisp, pero el proceso de aprendizaje fue duro
  • El comienzo fue equivocado. En Navidad me regalaron el libro CLtLv2 y empecé leyéndolo
  • Después descubrí el HyperSpec y comencé a leerlo, lo que encaminó mejor mi aprendizaje
• Common Lisp tenía características únicas
  • Es un lenguaje estandarizado, más parecido a C que a Java en ese sentido
  • Varios compiladores, intérpretes y runtimes implementan el estándar
  • Existen herramientas como Roswell para instalar y gestionar distintas implementaciones
  • La implementación más popular en la comunidad parece ser SBCL
• ¿Qué habría pasado si hubiera conocido Janet al empezar a explorar?
  • Janet tiene características que probablemente me habrían dejado satisfecho antes de aprender Common Lisp
  • Sintaxis concisa, ejecutables rápidos y pequeños, y soporte de C FFI
  • Existe una guía introductoria divertida
  • Cumplía con todos los requisitos que para mí eran importantes
• Pero elegí Common Lisp porque
  • Me habría perdido funciones avanzadas como CLOS y el Condition System, que conocí después
  • Common Lisp es un lenguaje más potente

Requisitos cumplidos

Después de confirmar que Common Lisp cumplía con los requisitos, lo elegí como mi siguiente lenguaje Lisp y lo sigo usando hasta hoy. Estos fueron los principales hallazgos:

• Ejecutables independientes:
  • En Common Lisp hay varias formas de crear ejecutables independientes
  • Según si el ejecutable está comprimido o no, el tiempo de arranque puede ir desde fracciones de segundo hasta ser casi instantáneo
  • Esta capacidad no está diseñada como una opción secundaria, sino como una forma principal de distribuir programas Lisp
• Flujo de trabajo con Vim:
  • Hay varias opciones excelentes, pero en lo personal armé mi propio flujo de trabajo en Vim
  • También comprobé que VS Code es suficientemente decente como IDE para Common Lisp
• Soporte para Windows/Mac/Linux:
  • SBCL ofrece buen soporte para los principales sistemas operativos
• Integración con ecosistemas imperativos grandes:
  • La mayoría de las implementaciones soportan bien la integración con C y se puede aprovechar mediante CFFI
• Velocidad en runtime:
  • SBCL es muy rápido en runtime
• Multithreading:
  • El estándar de Common Lisp no incluye soporte explícito para multithreading, pero las implementaciones principales sí lo ofrecen
  • La librería Bordeaux-Threads reduce las diferencias entre varias implementaciones
  • Librerías como lparallel, cl-async y blackbird permiten hacer multithreading y programación asíncrona
• Comunidad fuerte:
  • Descubrí la actividad de la comunidad y comencé a participar
  • Los resultados de la encuesta comunitaria de 2024 y el European Lisp Symposium muestran que la comunidad de Common Lisp está muy activa
  • También hay un fuerte apoyo comunitario en la red de blogs y en subreddit
• Ecosistema:
  • La mayoría usa Quicklisp, pero en lo personal gestiono paquetes con OCICL
  • Se pueden explorar librerías e información técnica en Common Lisp Cookbook, CLiki y Awesome CL
  • Soporte de librerías concretas:
    • JSON: jzon
    • Sqlite3: cl-sqlite
    • Requests HTTP: dexador
    • Estructuras de datos funcionales: FSet, cl-hamt

Nota para quienes recién empiezan

• Como cada vez llegan más principiantes al Discord de Common Lisp, escribí esto para compartir cómo elegí Common Lisp y cómo me adapté
• Espero que este texto sea útil para quienes estén interesados en Common Lisp

[GN⁺]

Comentarios en Hacker News

• Le impresionó la experiencia de resolver un problema usando SBCL incluso sin código fuente. Con otras pilas tecnológicas probablemente no habría podido corregirlo tan rápido sin acceso al código fuente

  • SBCL es un sistema muy dinámico, y pudo resolver el problema a través del REPL incluso sin código fuente

• Compartió su experiencia de pasar de Common Lisp a Clojure, y le resultaron atractivas las funciones de concurrencia de Clojure

  • babashka le fue útil para escribir scripts rápidos

• Usar vim-slime mejoró mucho la productividad y la satisfacción del desarrollador

  • Es útil porque permite usar el REPL en varios lenguajes
  • doom-emacs también se parecía a vim, por lo que podía aumentar la productividad

• No entendía el valor de Lisp, pero recordó una canción relacionada

• Afirmó que Emacs/slime es un mejor IDE para Lisp que vim-slime

  • Pudo resolver problemas de RSI cambiando el mapeo de teclas en Emacs

• Usa Common Lisp como hobby y quiere ejecutar código C# en el REPL de SBCL

  • El ciclo de retroalimentación es muy rápido y permite resolver problemas de inmediato

• Compartió su experiencia desarrollando aplicaciones CLI con Clojure y babashka

  • Pudo mejorar el rendimiento usando la biblioteca methodical

• Tuvo problemas al usar native-image y piensa que Clojure es un lenguaje casi perfecto

• Expresó interés por el lenguaje Janet y mencionó que el README y las FAQ del proyecto en GitHub son útiles

• Compartió una experiencia que le despertó el deseo de aprender Lisp, y le resultó especialmente atractivo que el autor fuera fan de vim

[gurugio]

No entendía el valor de Lisp, pero recuerdo una canción relacionada... hay muchas canciones sobre Lisp; en YouTube hay una canción llamada Land of Lisp ;-)