Mis pensamientos después de usar Clojure durante aproximadamente un mes

Funcional frente a POO y el diseño de Clojure

• Varios comentaristas parten de un entorno de POO y encuentran que el paradigma funcional resulta incómodo al principio, pero cada vez más convincente para sistemas grandes.
• Se considera que Clojure ofrece una especie de “POO a la carta” mediante maps/records, protocols, multimethods y schemas, aunque algunos sienten que esto es ad hoc en comparación con las jerarquías de clases tradicionales.
• Otros sostienen que la buena POO y la FP convergen en la práctica, y que la inmutabilidad omnipresente junto con transformaciones simples de datos hacen que el diseño a gran escala y la refactorización sean más fáciles.

Sintaxis, paréntesis y experiencia de edición

• Las opiniones sobre la sintaxis de Clojure están divididas: algunos la llaman “infierno de paréntesis”, mientras que otros dicen que los vectors/sets/maps y una sintaxis mínima del núcleo son una mejora neta frente a otros Lisps.
• Las herramientas de edición estructural (paredit, parinfer, navegación de sexp en Emacs, Ki editor, movimiento basado en indentación) se citan repetidamente como esenciales para gestionar corchetes y hacer que la refactorización sea agradable.
• Hay debate sobre elecciones sintácticas concretas (por ejemplo, enlaces let en vectors, el recorrido distinto de listas frente a vectors en otros Lisps).

Runtime, concurrencia y “sintaxis vs runtime”

• Un hilo importante sostiene que las propiedades del runtime (green threads, actors, STM, inmutabilidad) importan más que la sintaxis para los sistemas del mundo real.
• Algunos prefieren fuertemente los runtimes de Erlang/Elixir o Go para enormes cantidades de actores ligeros y diseños sin compartición de estado.
• Otros responden que la JVM es uno de los runtimes más avanzados, ahora con virtual threads, una concurrencia sólida y bibliotecas como Akka; las afirmaciones de que “va por detrás” se consideran desfasadas.
• Se reconoce STM y actores en la JVM, pero se ven como menos idiomáticos o menos usados que el modelo integrado de BEAM.

LLMs, Clojure y el REPL

• Los benchmarks muestran que los LLMs en bruto tienen tasas de “éxito” de un solo intento más bajas en Clojure (sintaxis, paréntesis, orden de evaluación), pero cuando se conectan a un REPL de Clojure pueden probar código iterativamente y volverse mucho más efectivos.
• El desarrollo guiado por REPL se presenta como una superpotencia, tanto para humanos como para agentes LLM, ya que permite exploración incremental, depuración y descubrimiento de bibliotecas.

Tipado, specs y fiabilidad

• Algunos comentaristas tienen dificultades con el tipado dinámico, y reportan errores sutiles en tiempo de ejecución y la ausencia de garantías en tiempo de compilación que obtienen de lenguajes FP tipados.
• Otros defienden la dinamización intencional de Clojure y sugieren apoyarse en el REPL más schemas/spec (por ejemplo, Malli, spec, Typed Clojure en investigación/uso limitado) para comprobaciones estáticas parciales y validación de datos.
• Una postura fuerte afirma que el tipado dinámico siempre es un error; otros no están de acuerdo y enfatizan los compromisos y la productividad.

Portabilidad y ecosistema

• Clojure se destaca como un lenguaje hospedado con muchos dialectos (JVM, JS, CLR, Dart, babashka, C++, Python-hosted, etc.).
• Se está usando un test suite compartido de clojure.core para medir y mejorar la compatibilidad entre dialectos.
• Esta portabilidad se presenta como una ventaja importante: mucho código “puro” de Clojure puede ejecutarse sin cambios entre runtimes.

Empleos, popularidad y economía

• Algunos señalan que hay relativamente pocas ofertas de trabajo de Clojure y ven eso como una falta de atractivo en el mercado.
• Otros responden que los puestos de Clojure suelen pagar por encima de la media y señalan contrataciones no comoditizadas; la popularidad y el número de empleos no se corresponden directamente con el mérito técnico.
• La discusión distingue entre “sinergia” y política (por ejemplo, la adopción de Python, JS, C#, PHP) y la calidad del lenguaje.

Generadores de sitios estáticos y juguetes lispy

• Varios comentaristas mencionan haber escrito sus propios generadores de sitios estáticos en Clojure u otros Lisps como un rito de paso.
• Los SSG caseros son divertidos y fáciles de ampliar con macros/plantillas, pero se quedan cortos frente a herramientas maduras en optimización, manejo de CSS, SSR e integración con el ecosistema de Node; muchos acaban migrando a SSGs convencionales.