El artículo muestra cómo el autor移植ó The Elm Architecture (TEA) —el clásico bucle init/update/subscriptions— a un trabajo por lotes de back-office escrito en Elm y ejecutado con elm-run, el proyecto de Damir que lleva Elm al sistema operativo. Frente al enfoque de pipeline de elm-pages Script (útil para tareas lineales como leer un RSS, transformar y publicar), elm-run mantiene un modelo vivo y mensajes circulando, lo que resulta clave cuando hay que coordinar cientos de elementos que avanzan a ritmos distintos, fallan a mitad de camino y necesitan reintentos.
La pieza clave del diseño es que cada elemento del lote es una máquina de estados minúscula definida con un tipo suma: Queued, Submitted, Processing, Finished o Failed. Las transiciones son funciones cuyas firmas hacen imposible pasar de Submitted a Processing algo que aún está Queued, o pedir un resultado a un elemento sin Ref. El autor lo describe como “programación orientada a ferrocarril con más estaciones”: el Result de Scott Wlaschin es el caso degenerado; aquí se añaden paradas intermedias.
El estado Failed conserva el Item anterior completo, de modo que rewind recupera la posición exacta previa al fallo. Un excepción amnesia dónde estabas; este fallo es un punto de control con dirección de retorno. Para un lote de cientos de ítems, “el proceso cayó al 64 %” es un desastre, mientras que “283 acabados, 4 estacionados” es un martes cualquiera. La exhaustividad en el case y la inmutabilidad hacen que refactorizar no dé miedo: cambiar la forma de un paso obliga al compilador a revisar todos los productores y consumidores, incluido el rewind. Frente a un worker imperativo en Python o Bash, el mismo dominio se convierte en ciudadano de primera clase, escrito con el mismo rigor que la UI. El artículo cierra adelantando que los mismos tipos de Elm (codificadores, decodificadores, lógica de dominio) correrán en tres runtimes distintos gracias a Lamdera y elm-run.