Llevarse la filosofía sin llevarse el lenguaje

Existe un patrón que se repite con una regularidad casi cómica entre quienes pasan una temporada con Elm y luego vuelven a su lenguaje habitual: no lo abandonan, pero empiezan a escribirlo con acento. Modelan el estado con uniones etiquetadas donde antes ponían tres banderas booleanas independientes, devuelven el fallo en vez de lanzarlo, validan el dato en la frontera en lugar de comprobarlo cinco veces por dentro, y desarrollan una alergia repentina a los valores que pueden faltar sin que el tipo lo diga. Ese efecto es la aportación más medible de Elm a la industria, mucho más amplia que su cuota de uso, y no se explica porque enseñe técnicas nuevas —casi todas existían antes en la tradición funcional tipada—, sino porque las lleva al extremo y no ofrece alternativa, de modo que el aprendizaje no queda como una preferencia estilística sino como un hábito. La pregunta práctica es qué parte de ese hábito sobrevive al regreso a un lenguaje permisivo, y la respuesta depende menos del lenguaje de destino de lo que suele suponerse y mucho más de dónde se coloque el punto de obligación.

Los principios y su equipaje

El primero y más rentable es hacer imposibles los estados inválidos. En Elm se expresa con un tipo unión cuyos constructores llevan justo los datos que ese estado necesita, de modo que no existe la combinación de un cargando verdadero con unos datos ya presentes. Viaja completo a Rust y a Swift, cuyos tipos enumerados con valores asociados son el mismo mecanismo con otro nombre, y viaja bastante bien a TypeScript mediante uniones discriminadas por una etiqueta literal. El segundo es tratar la ausencia y el fallo como valores en vez de como sucesos: Option y Result en Rust, el opcional y el tipo de resultado en Swift, y en TypeScript la unión con null bajo comprobación estricta más un resultado explícito en lugar de lanzar. El tercero es la exhaustividad, que Rust y Swift imponen en su construcción de selección y que TypeScript solo consigue con un chequeo auxiliar sobre el tipo never.

-- El principio en su forma original: el estado imposible no se escribe
type EstadoRemoto error dato
    = NoPedido
    | Cargando
    | Fallo error
    | Cargado dato


-- No existe la combinacion cargando mas datos presentes,
-- ni la de fallo mas datos presentes, porque no hay como escribirla.
ver : EstadoRemoto String Int -> String
ver estado =
    case estado of
        NoPedido ->
            "sin pedir"

        Cargando ->
            "cargando"

        Fallo mensaje ->
            "error: " ++ mensaje

        Cargado n ->
            String.fromInt n

Lo que llega debilitado y lo que no llega

La frontera validada es el principio que más rendimiento da y el que peor viaja, no por falta de herramientas sino porque nada obliga a usarlas. Cualquiera de los tres lenguajes permite convertir el dato externo en un valor del dominio en el punto de entrada, con las bibliotecas de esquema de TypeScript, con la serialización dirigida por tipos de Rust o con los protocolos de codificación de Swift. La diferencia es que en Elm no hay otra manera de entrar, y fuera de Elm siempre queda el atajo de afirmar el tipo sin comprobarlo. Lo mismo ocurre con la pureza: puedes escribir un núcleo de funciones sin efectos y empujar la entrada y la salida a un borde delgado, pero ningún compilador te avisará si un día alguien escribe una lectura de reloj en medio de la lógica.

-- Cuarto principio: el dato externo se convierte en dominio al entrar
type Correo
    = Correo String


-- El unico constructor publico valida. Fuera del modulo
-- no hay forma de fabricar un Correo que no haya pasado por aqui.
desdeTexto : String -> Result String Correo
desdeTexto texto =
    if String.contains "@" texto then
        Ok (Correo (String.toLower (String.trim texto)))

    else
        Err "formato invalido"


aTexto : Correo -> String
aTexto (Correo valor) =
    valor

Ese patrón es el que mejor sobrevive fuera de Elm, y conviene entender por qué. No depende de que el lenguaje prohíba nada, sino de que la única puerta de construcción esté cerrada por el sistema de módulos: un constructor privado, una función pública que valida y un tipo que a partir de ahí significa dato correcto. TypeScript lo consigue con un tipo marcado y un constructor exportado en solitario, Rust con un campo privado dentro de su módulo y Swift con un inicializador que puede fallar y un almacenamiento privado. En los tres casos, quien escriba código nuevo dentro de seis meses no necesita conocer ninguna norma del equipo: la única forma de obtener el valor es la correcta, porque no hay otra. Esa es exactamente la estrategia de Elm aplicada al nivel del módulo en vez del lenguaje, y es la única que no se erosiona con la rotación de personas.

Y hay una parte que sencillamente no se puede llevar: la garantía global. En Elm, la ausencia de excepciones es una propiedad del lenguaje que se cumple aunque tu equipo sea descuidado y aunque tus dependencias las escribieran desconocidos. En cualquier otro sitio, lo máximo alcanzable es una propiedad local del código que tú controlas, sostenida por configuración y revisión, y que se detiene en el borde de la primera biblioteca ajena. Esa diferencia no es un matiz: es la razón por la que un proyecto disciplinado en un lenguaje permisivo se parece a Elm en los buenos días y no se le parece en los malos.

La disciplina mecanizada

Una regla de equipo que solo vive en la cabeza de las personas dura hasta la primera entrega con prisa, así que la única disciplina que cuenta es la que está escrita en la configuración y falla la construcción. En TypeScript eso significa activar el modo estricto completo, prohibir el tipo comodín con una regla que rompa el análisis en vez de avisar, prohibir la afirmación de tipo sin comprobación y exigir el chequeo exhaustivo en las uniones. En Rust significa prohibir el bloque inseguro en el archivo raíz salvo excepción documentada, y tratar como error los avisos que señalan resultados ignorados. En Swift significa vetar el desempaquetado forzoso mediante análisis estático y aislar los pocos puntos donde se acepta.

flowchart LR
P[Principio de Elm] --> T[Traduccion idiomatica]
T --> M[Mecanizada en la construccion]
T --> N[Solo acordada en el equipo]
M --> G[Propiedad local fiable]
N --> O[Se pierde en la primera urgencia]
G --> L[Limite: dependencias ajenas]
style M fill:#a6e3a1,color:#11111b
style N fill:#f38ba8,color:#11111b
style L fill:#f9e2af,color:#11111b

Hay un segundo nivel de mecanización que se pasa por alto y que es el más rentable en equipos grandes: colocar la obligación en el tipo y no en la regla. Si el único constructor público de un identificador de usuario es una función que valida, ningún compañero podrá fabricar uno inválido aunque nadie revise su cambio, y no hará falta ninguna norma escrita. Ese patrón —tipos que solo pueden construirse por el camino correcto— es la forma en que las ideas de Elm sobreviven mejor fuera de Elm, porque no dependen de que nadie recuerde nada.

La garantía que queda

Al final del traslado conviene enunciar con precisión qué se puede afirmar, porque exagerarlo arruina la credibilidad del que lo intenta. Lo alcanzable en un lenguaje permisivo con configuración estricta y buen diseño de tipos es una propiedad de esta forma: dentro del código que controlamos, los estados inválidos no son representables, los fallos aparecen en las firmas, el dato externo se valida en un único punto y añadir un caso a una unión rompe la compilación donde debe. Eso es mucho, cubre la mayor parte de los fallos que ese equipo produciría, y se detiene exactamente en el borde de la primera dependencia ajena y en cualquier archivo donde alguien haya desactivado una regla con un comentario.

La honestidad sobre ese límite es lo que separa la práctica madura del entusiasmo del converso. Quien afirma que su proyecto en un lenguaje permisivo tiene las garantías de Elm no ha entendido la diferencia entre una propiedad construida y una propiedad vigilada, y perderá la discusión en cuanto alguien encuentre el primer contraejemplo en una biblioteca de terceros. Quien afirma que ha reducido drásticamente una clase de fallos en la parte del sistema donde tiene autoridad está diciendo algo verdadero, defendible con datos y suficiente para justificar el esfuerzo ante cualquier persona razonable.