Cero errores en runtime: el alcance exacto de la promesa

Una promesa que no se puede refutar no dice nada, y por eso la frase de Elm es interesante: afirma algo lo bastante concreto como para que un solo contraejemplo la derribe. Ese rigor tiene un precio simétrico que casi nadie paga al citarla, porque la frase circula recortada, sin la letra que la acota, y termina significando dos cosas distintas según quién la pronuncie. En boca del escéptico se convierte en la caricatura de un lenguaje que promete programas perfectos, caricatura fácil de demoler con el primer bug de negocio que alguien encuentre. En boca del entusiasta se convierte en una licencia para no probar nada, porque si compila funciona. Ambas lecturas son falsas, y lo son por el mismo motivo: confunden la consistencia de un sistema de tipos con la corrección de un programa. Un sistema de tipos consistente garantiza que la ejecución nunca alcanza un estado que el lenguaje no sepa describir. Un programa correcto es el que hace lo que su especificación pide. Entre esas dos propiedades hay un abismo, y toda la filosofía de Elm consiste en haber decidido con una precisión inusual en qué lado de ese abismo quiere ofrecer certezas y en qué lado se limita a ayudarte.

Lo que la promesa afirma

La formulación precisa no habla de programas sin fallos: habla de una clase de fallos que deja de ser expresable. La ejecución de un programa puede detenerse antes de tiempo por razones muy distintas, y Elm cierra las que nacen de una discrepancia entre lo que el código supone y lo que el valor es. Desaparece la desreferencia de un valor ausente, porque no existe un valor comodín que habite todos los tipos. Desaparece el fallo no tratado, porque no hay un canal de retorno invisible por el que un error pueda escapar. Desaparece el caso no cubierto, porque el case obliga a enumerar todos los constructores. Y desaparece la sorpresa de la frontera, porque nada externo entra sin declarar su forma. El resultado no es un programa correcto: es un programa cuya ejecución nunca alcanza un estado indefinido.

-- Este programa compila, no lanza nada y esta mal
-- El tipo es cierto: devuelve un Int. El negocio es falso.
precioConDescuento : Int -> Int -> Int
precioConDescuento base porcentaje =
    base - (base * porcentaje // 100) - 1


-- El compilador confirma que hay un Int al final.
-- Nadie confirma que ese Int sea el precio que el cliente debe pagar.

Los residuos reconocidos

Hay maneras de detener un programa Elm, y enumerarlas honestamente refuerza el enunciado en vez de debilitarlo, porque una promesa que se sabe sus propios límites es más creíble que una promesa absoluta. Debug.todo detiene la ejecución a propósito y existe para marcar trabajo pendiente durante el desarrollo. La recursión sin caso base no termina, y ningún tipo habla del tiempo. Una recursión demasiado profunda agota la pila del entorno anfitrión, que es una limitación de la máquina y no del lenguaje. La aritmética en coma flotante produce valores especiales en vez de detenerse, lo cual evita la excepción pero propaga un número sin sentido. Y el arranque desde el anfitrión puede fallar si el nodo del documento no existe.

-- Los residuos, uno por uno
sinImplementar : Int -> Int
sinImplementar n =
    Debug.todo "pendiente"


noTermina : Int -> Int
noTermina n =
    noTermina (n + 1)


-- Un fallo enmascarado: no rompe, pero miente
edadDelUsuario : Int
edadDelUsuario =
    Maybe.withDefault 0 (String.toInt "treinta")

El territorio que queda

El tercer ejemplo del bloque anterior es el más instructivo de los tres, porque no es un residuo del lenguaje sino una consecuencia estructural de la garantía. Al obligar a tratar la ausencia, Elm te empuja a decidir qué ocurre cuando el dato falta, y esa decisión puede ser mala. Un Maybe.withDefault 0 mal colocado convierte una excepción ruidosa en un dato silenciosamente falso que viaja por el sistema, entra en una suma, sale por un informe y termina en una factura. Ese intercambio es real y merece nombrarse: la garantía transforma fallos ruidosos en decisiones explícitas, y una decisión explícita tomada con desgana es un bug de lógica con muy buena presentación.

flowchart TD
P[Programa que compila] --> A[Clase eliminada por construccion]
P --> B[Residuos reconocidos]
P --> C[Bugs de logica]
A --> A1[Valor ausente no tratado]
A --> A2[Caso no cubierto]
B --> B1[Todo explicito o pila agotada]
C --> C1[El modelo del dominio es falso]
C --> C2[El valor por defecto miente]
style A fill:#a6e3a1,color:#11111b
style B fill:#f9e2af,color:#11111b
style C fill:#f38ba8,color:#11111b

-- La exhaustividad obliga a decidir, pero no juzga la decision
type Suscripcion
    = Gratuita
    | Mensual
    | Anual
    | Cortesia


descuento : Suscripcion -> Int
descuento suscripcion =
    case suscripcion of
        Gratuita ->
            0

        Mensual ->
            10

        Anual ->
            20

        -- Compila, cubre el caso y regala el producto entero
        Cortesia ->
            100

Queda además la categoría más grande de todas, la que ningún sistema de tipos de ningún lenguaje ha reducido jamás: el programa hace exactamente lo que escribiste y lo que escribiste no era lo que el negocio necesitaba. Aquí Elm no ofrece garantías, ofrece condiciones. Un modelo que hace imposibles los estados inválidos reduce el espacio en el que un malentendido puede esconderse. Un tipo unión con nombres del dominio convierte una conversación con la persona experta en una estructura revisable. La exhaustividad obliga a preguntar qué pasa en el caso raro justo cuando aún hay tiempo de preguntarlo. Nada de eso es una demostración de corrección, pero todo eso desplaza los errores hacia el momento en que salen baratos.

Cómo enunciarla sin exagerar

Esa reorientación de las pruebas merece un desarrollo, porque es el efecto práctico más inmediato en el día a día de un equipo. En un lenguaje permisivo, una parte considerable de la batería de pruebas existe para vigilar formas: comprobar que la función tolera un valor ausente, que no revienta con una lista vacía, que el objeto de respuesta traía los campos esperados. Todas esas pruebas desaparecen en Elm, no porque alguien decida borrarlas, sino porque el escenario que verificaban no es construible y el caso de prueba ni siquiera se puede escribir. Lo que queda es el conjunto de pruebas que interroga al dominio: si el descuento acumulado respeta el mínimo legal, si el estado de la sesión caduca cuando debe, si el orden de dos mensajes concurrentes produce el resultado correcto. Esa batería es más pequeña, más difícil de escribir y muchísimo más valiosa, y su existencia depende por completo de que alguien haya entendido el problema, que es precisamente donde la garantía del compilador termina.

La formulación defendible cabe en dos frases. Primera: en Elm, un programa que compila no lanza excepciones en tiempo de ejecución, salvo por un conjunto pequeño, conocido y documentado de residuos que el programador introduce a propósito o que pertenecen al entorno anfitrión. Segunda: esa garantía no dice absolutamente nada sobre si el programa hace lo que debe. Quien enuncia así la promesa no puede ser acusado de vender humo, porque ha declarado el alcance antes de que se lo pidan, y tampoco puede ser confundido con alguien que cree que el compilador sustituye a las pruebas.