Las herramientas: elm make, elm repl, elm reactor y el bucle corto

Casi todos los ecosistemas modernos de desarrollo de interfaces exigen, antes de escribir una línea útil, una inversión considerable en decidir con qué se va a construir: un empaquetador entre varios, una configuración que crece durante años, una cadena de transformaciones del código fuente, un comprobador de tipos separado del compilador, un formateador con sus opciones discutidas en reuniones, un analizador estático con centenares de reglas activables y el pegamento que hace que todo eso coopere. Ese trabajo tiene un nombre que la profesión ha normalizado sin protestar, que es configurar el proyecto, y consume una fracción de tiempo que nadie contabiliza. Elm hizo la apuesta contraria y la hizo entera: un solo binario, cuatro verbos, un archivo declarativo de dependencias y ninguna opción que discutir. La consecuencia no es solo comodidad. Cuando la herramienta desaparece de la conversación, el bucle entre escribir y saber si funciona se acorta hasta volverse casi instantáneo, y ese bucle corto es, mucho más que cualquier característica del lenguaje, lo que la gente describe cuando dice que programar en Elm se siente distinto.

Un binario y cuatro verbos

El instrumental oficial se aprende en una tarde y no cambia entre proyectos. Un comando crea el archivo declarativo de dependencias, otro compila, otro abre una sesión interactiva, otro levanta un servidor de desarrollo y otro instala paquetes. No hay archivo de configuración del compilador, no hay complementos, no hay canalización que definir y no hay una forma alternativa de hacer lo mismo. La homogeneidad tiene un efecto que se aprecia al abrir un proyecto ajeno: se compila igual que el tuyo, con los mismos comandos y sin leer nada.

# Crear el proyecto: genera elm.json y src/
elm init

# Compilar a JavaScript
elm make src/Main.elm --output=app.js

# Modo depuracion: incluye el depurador con historial de mensajes
elm make src/Main.elm --output=app.js --debug

# Produccion: elimina codigo muerto y acorta nombres
elm make src/Main.elm --optimize --output=app.js

# Solo comprobar tipos, sin generar nada
elm make src/Main.elm --output=/dev/null

# Salida estructurada para que la consuma otra herramienta
elm make src/Main.elm --report=json

Los dos modos merecen una nota porque son excluyentes y esa exclusión es deliberada. El modo de depuración inyecta en el artefacto la maquinaria necesaria para registrar cada mensaje y cada modelo intermedio, lo cual engorda el resultado y ralentiza la ejecución; el modo de optimización elimina todo lo que no sea alcanzable, acorta los nombres internos y elimina las llamadas de rastreo. Pedir los dos a la vez no es posible, y el compilador se niega además a construir en modo optimizado si queda algún marcador de trabajo pendiente en el código, lo cual convierte un descuido en un error de compilación en el único momento en que importa.

La instalación de dependencias completa el cuadro y merece una observación. El comando de instalación no descarga lo que le pidas sin más: resuelve el conjunto entero de restricciones y se niega si no existe una combinación de versiones compatible, en lugar de dejar el proyecto en un estado que compila hoy y falla mañana. Como todas las versiones publicadas cumplen el versionado que estudiaremos en la lección siguiente, el resolutor puede razonar sobre los intervalos con certeza y no con heurísticas.

# Anadir una dependencia: resuelve restricciones o se niega
elm install elm/http

# Las dependencias directas e indirectas quedan fijadas en elm.json

El bucle corto

La unidad de trabajo real no es el comando sino el ciclo: escribir, guardar, saber. Que ese ciclo dure uno o quince segundos no es una diferencia cuantitativa sino cualitativa, porque por debajo de cierto umbral el programador no cambia de contexto y por encima sí. Elm sostiene el bucle corto gracias a una propiedad que rara vez se menciona en las comparaciones y que es probablemente su ventaja práctica más grande: el compilador reconstruye el proyecto entero en un tiempo que se mide en fracciones de segundo incluso en bases de código considerables, porque no hay que resolver sobrecargas, no hay que ejecutar código en tiempo de compilación y no hay una cadena de transformaciones intermedias.

Merece la pena detenerse en lo que esa velocidad hace posible, porque no es solo comodidad. Un compilador lento obliga a cambiar de estrategia: como preguntar es caro, el programador escribe tramos largos antes de comprobar, y al comprobar recibe varios errores mezclados cuyas causas se enredan entre sí. Un compilador instantáneo permite la estrategia contraria, que es preguntar después de cada decisión pequeña y no acumular nunca más de un problema a la vez. La diferencia entre ambas formas de trabajar no se mide en segundos ahorrados sino en cuántos hilos mentales hay que sostener simultáneamente, y esa es la variable que decide si una tarde de trabajo resulta agotadora o fluida.

-- El archivo de dependencias es declarativo y no configura al compilador
-- elm.json, en su forma minima para una aplicacion
-- type          : application
-- source-directories: src
-- elm-version   : 0.19.1
-- dependencies  : directas e indirectas, con version exacta

La sesión interactiva y el depurador que viaja al pasado

La sesión interactiva de Elm no es un intérprete alternativo sino el mismo compilador respondiendo expresión a expresión, y su utilidad principal no es calcular sino preguntar tipos. Escribir el nombre de una función desconocida y leer su firma es más rápido que buscarla en la documentación, y encadenar dos funciones para ver qué tipo sale es la forma más directa de averiguar por qué una composición no encaja. Conviene recordar que las definiciones de la sesión no persisten y que hay que importar los módulos que se quieran usar.

elm repl
> import String exposing (..)
> String.split "," "a,b,c"
["a","b","c"] : List String

> import Maybe
> Maybe.andThen
<function> : (a -> Maybe b) -> Maybe a -> Maybe b

# Servidor de desarrollo con navegador de archivos en el puerto 8000
elm reactor

El depurador es la pieza que más sorprende a quien llega de otros entornos, y su existencia no es un logro de ingeniería de herramientas sino una consecuencia directa de la arquitectura. Como todo cambio de estado pasa por un mensaje, como la función de actualización es pura y como el modelo es un valor inmutable, la historia completa de una sesión es simplemente la lista de mensajes recibidos. Registrarla es trivial, reproducirla es determinista y volver a cualquier punto del pasado consiste en recalcular desde el principio. El depurador permite además exportar ese historial a un archivo y que otra persona lo importe, de modo que un informe de fallo puede consistir en la secuencia exacta de acciones que llevó al problema en lugar de una descripción aproximada.

flowchart LR
E[Editor guarda] --> M[elm make comprueba tipos]
M --> J[Salida estructurada]
J --> D[Diagnosticos en el editor]
J --> Q[Lista de saltos]
D --> E
M --> R[elm reactor recarga]
R --> B[Depurador con historial]
style M fill:#a6e3a1,color:#11111b
style D fill:#89b4fa,color:#11111b
style B fill:#cba6f7,color:#11111b

El editor como superficie del compilador

El último paso convierte todo lo anterior en algo que no hay que invocar. El servidor de lenguaje de la comunidad no reimplementa el análisis: llama al mismo compilador pidiéndole la salida estructurada y traduce el resultado al protocolo que el editor entiende. Eso tiene una consecuencia importante y poco habitual, y es que los diagnósticos que ves mientras escribes son literalmente los mismos que verás al construir, sin discrepancias entre lo que dice el editor y lo que dice la herramienta de integración continua.

# Piezas que conviene tener enganchadas al editor
elm-language-server   # diagnosticos, ir a definicion, autocompletado
elm-format            # formato canonico sin opciones, al guardar
elm-test              # pruebas unitarias y basadas en propiedades
elm-review            # analisis con reglas propias del proyecto

En un editor de la familia de Vim la integración natural aprovecha dos mecanismos que ya conoces de otros niveles de esta guía. El primero es el cliente de protocolo de lenguaje, que sitúa los diagnósticos junto a la línea culpable y permite saltar entre ellos sin salir del archivo. El segundo es la lista de saltos, que recibe la salida del compilador convertida en una colección de posiciones y convierte el refactor dirigido por errores de la lección anterior en un recorrido mecánico: se arregla el primero, se salta al siguiente y se repite hasta que la lista queda vacía. Añadir el formateador al guardar cierra el círculo, porque elimina de la revisión de código toda discusión que no sea sobre el fondo.