LSP en Haskell: el live reload que se acerca a Lisp

El flow "vivo" de Lisp y por qué importa a un founder

Para un fundador técnico, una de las decisiones más subestimadas es qué tan rápido puede iterar su equipo. El post original, publicado en entropicthoughts.com, narra la frustración de un desarrollador con años de experiencia que describe su flujo habitual: editar en el editor, saltar a la terminal, compilar, ejecutar, mirar el resultado y volver al editor. Es un ciclo perfectamente funcional, pero lento comparado con lo que hacen los programadores de Lisp, que modifican el sistema en vivo dentro del REPL.

En el ecosistema hispanohablante de startups, donde los equipos suelen ser pequeños y cada hora de ingeniería cuenta, esa diferencia entre "compilar, ejecutar, depurar" y "editar código vivo" se traduce en días enteros de tiempo de producto al año. El propio autor lo resume con una lista de privilegios que da el REPL: no hace falta "cambiar a" otra ventana, no se compila, no se reinicia el debugger y, gracias al sistema de condiciones de Lisp, ni siquiera hay que reiniciar el programa cuando una excepción lo rompe.

Qué es un Language Server Protocol (LSP) y por qué debería importarte

El Language Server Protocol (LSP) es un estándar abierto que define cómo un editor habla con un servidor que entiende a fondo un lenguaje. El servidor ofrece completado de código, documentación inline, navegación entre definiciones, refactor y diagnósticos. El editor solo se encarga de mostrar esa información.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

Según una pieza de TechTimes, el servidor oficial de Go (gopls) trabaja con VS Code, Vim, Emacs y otros editores compatibles, y su versión 0.12 logró reducciones de uso de memoria y mejoras de tiempo de arranque de aproximadamente un 75%. Eso es solo un caso: hoy existen servidores LSP para los lenguajes más usados (TypeScript, Rust, Python, Go, Haskell, Elixir, Kotlin), y la mayoría de editores modernos los soportan de forma nativa o vía plugin.

La implicación práctica para un CTO es directa: cuando tu equipo dice que un editor "va lento" o que el autocompletado "no funciona", nueve de cada diez veces el problema es que el language server no está bien configurado, no que la herramienta sea mala.

El experimento: replicar el REPL de Lisp en Haskell

El artículo cuenta el intento concreto de armar ese flujo "vivo" en Haskell, un lenguaje compilado donde, por defecto, no existe un REPL práctico para desarrollo de aplicación. La receta que terminó funcionando combina cuatro piezas:

hls (Haskell Language Server): el servidor LSP para Haskell, que ofrece introspección de tipos, completado y acciones de código desde el editor.
Eglot: el cliente LSP integrado en Emacs, que se conecta a hls sin necesidad de paquetes de terceros.
ghcid: una herramienta que vigila cambios en archivos Haskell y recompila al instante; además, puede ejecutar una función definida por el usuario tras cada recompilación exitosa.
foreign-store: una biblioteca que permite mantener estado en memoria entre recargas, simulando el "no perder el programa" del REPL de Lisp.

El flujo final descrito por el autor es: escribir código y tests en el editor, guardar el archivo y, sin levantarse de la silla, ver cómo los tests se ejecutan y la visualización del proyecto se actualiza automáticamente. Para su caso concreto, una visualización de ecuaciones diferenciales, eso significa cambiar una constante y observar el nuevo gráfico sin reiniciar nada.

El precio de la potencia: por qué no es trivial

El propio artículo es honesto con los costos de montar este entorno. El setup inicial con Nix, direnv, flakes y la configuración de Eglot llevó una cantidad significativa de pasos y varias idas y vueltas. El autor destaca fricciones reales que vale la pena leer con atención antes de elegir stack:

La latencia agregada por el servidor LSP entorpece algunos comandos rápidos de edición. El autor lo describe como suficientemente molesto para impedirle usar Eglot en otros proyectos.
Eglot a veces necesita reconectarse tras añadir dependencias nuevas al archivo cabal.
ghcid solo soporta un único componente de proyecto, lo que obliga a co-localizar todo el código en un solo paquete, una decisión inaceptable para proyectos de producción.
La documentación "pop-up" de Eglot rompe configuraciones como el centrado del cursor en Emacs.

El comentario que cierra el post lo dice sin rodeos: en Python con VS Code, todo esto funciona "out of the box", y compara la complejidad del setup en Haskell con la de un cirujano operando un cohete. La brecha es real. Los lenguajes interpretados o con REPL maduro (Python, Ruby, JavaScript, Lisp, Elixir) ofrecen iteración rápida casi sin esfuerzo. Los lenguajes compilados con sistemas de tipos estrictos (Haskell, Rust, Scala) entregan más seguridad, pero piden más trabajo para acercarse a esa experiencia.

Qué significa esto para tu startup

Si lideras un equipo de ingeniería, esta historia deja tres decisiones prácticas que rara vez aparecen en los tableros de KPIs:

Evalúa la velocidad de iteración, no solo la velocidad de ejecución. Un lenguaje o framework que se reinicia en tres segundos puede matar la productividad de un equipo de cinco ingenieros más rápido que cualquier bug en producción. Antes de elegir stack, prueba cuánto tarda un cambio pequeño en llegar a una pantalla o un log.
Invierte una tarde en configurar bien el LSP de tu stack. En VS Code, Cursor, Emacs o Neovim, activar el language server del lenguaje principal es usualmente la mejora de productividad más barata que puedes hacer. No tiene que ser Haskell: aplica igual a TypeScript (tsserver), Python (pyright), Rust (rust-analyzer) o Elixir (elixir-ls).
Trata el "REPL-driven workflow" como feature, no como capricho. Lenguajes como Elixir, Clojure y Ruby on Rails permiten experimentar con el sistema en ejecución, lo que reduce el ciclo de feedback de horas a segundos. Si tu producto depende de iteración rápida sobre lógica de negocio, ese detalle de tooling puede importar más que el rendimiento bruto.

Acciones concretas que puedes aplicar esta semana:

Pide a tu equipo que mida cuánto tarda hoy un cambio de una línea en verse reflejado en el entorno de pruebas local. Si pasa de cinco segundos, hay margen claro de mejora.
Audita qué language servers tienen activados los editores de tu equipo. Muchas veces ni siquiera están habilitados.
Si estás eligiendo stack para un nuevo producto, prueba el flujo de desarrollo del lenguaje candidato antes de mirar benchmarks de rendimiento.
Reserva una hora para que el equipo documente el setup del entorno de desarrollo en el README del repositorio. Es la documentación que casi nadie escribe y que más cuesta cuando alguien nuevo entra.