El coste de las garantías: un lenguaje sin escotillas

Cuando un sistema de tipos impide algo que el programador sabe correcto, existen dos respuestas posibles y ambas tienen defensores serios. La primera consiste en abrir una puerta explícita y marcada por la que se pueda pasar bajo la propia responsabilidad, con la expectativa de que se usará poco y con cuidado; es la respuesta de casi toda la industria y tiene a su favor un argumento difícil de rebatir, que es la existencia comprobable de casos donde el compilador está equivocado. La segunda consiste en no abrir ninguna puerta y aceptar que habrá trabajos que no se puedan hacer, con la expectativa de que la ausencia de puertas produce una propiedad que ninguna cantidad de disciplina puede reproducir. Elm eligió la segunda, y lo hizo sabiendo que perdía cosas concretas y valiosas. Entender esa elección exige resistir la tentación de calificarla de purismo, porque no nace de un gusto estético sino de un análisis sobre cómo se propagan las garantías en un sistema formado por código propio, código ajeno y personas con plazos.

Las puertas que no existen

El inventario es más largo de lo que parece a primera vista, y cada ausencia cierra una vía distinta. No hay conversión insegura de tipos ni nada equivalente a un tipo comodín que acepte cualquier valor. No hay forma de llamar a una función de JavaScript desde una función Elm y recibir su resultado: la comunicación con el anfitrión pasa por puertos, que son asíncronos por construcción, o por elementos personalizados, que viven en la frontera del documento. Ningún paquete publicado puede incluir código JavaScript propio, restricción endurecida a propósito para que la garantía no dependa de la buena fe de terceros. No hay macros ni generación de código en tiempo de compilación. No hay reflexión. No hay excepciones que capturar. Y las herramientas de depuración que sí existen quedan prohibidas al compilar en modo optimizado, para que no se cuelen en producción.

-- No existe esto: una llamada directa que devuelva el valor
-- anchoDelTexto : String -> Float   -- imposible en Elm puro

-- Existe esto: un mensaje que sale y una suscripcion que recibe
port medirTexto : String -> Cmd msg


port textoMedido : (Float -> msg) -> Sub msg


-- La consecuencia de diseno: cualquier dato del exterior
-- llega mas tarde y llega como un Msg mas del bucle.

Lo que eso te impide

La factura se paga sobre todo en integración. Envolver un componente de JavaScript con estado propio —un editor enriquecido, un mapa, una biblioteca de gráficos— exige un elemento personalizado y un protocolo de atributos, cuando en otro lenguaje bastaría con una llamada. Cualquier lectura del documento que en JavaScript sería inmediata, como medir un elemento antes de pintar, se convierte en un viaje de ida y vuelta que atraviesa el bucle y que llega un fotograma más tarde. Una interfaz nueva del navegador no está disponible hasta que alguien escribe el paquete o el puerto correspondiente. Y en el terreno del rendimiento no hay recurso: si un bucle concreto necesita una estructura mutable para ser aceptable, no puedes escribirla, solo puedes remodelar el problema o mover esa parte al anfitrión.

-- La valvula que si existe: alojar un widget ajeno como nodo
verEditor : String -> Html Msg
verEditor contenido =
    Html.node "editor-enriquecido"
        [ Html.Attributes.attribute "contenido" contenido
        , Html.Events.on "cambio" decodCambio
        ]
        []


-- Y el dato que vuelve entra por la aduana, como cualquier otro
decodCambio : Decode.Decoder Msg
decodCambio =
    Decode.map ContenidoCambiado
        (Decode.at [ "detail", "texto" ] Decode.string)

Por qué una escotilla no es local

Antes de entrar en el argumento conviene formular la objeción en su versión más razonable, porque la caricatura no sirve de nada. Quien defiende las escotillas no dice que haya que usarlas siempre; dice que existen casos comprobables en los que el programador dispone de información que el sistema de tipos no puede expresar, que en esos casos el trabajo no debería detenerse, y que marcar explícitamente esas regiones concentra la revisión donde hace falta en vez de dispersarla. Es un argumento serio y funciona bien en lenguajes donde la región marcada es pequeña, auditable y culturalmente sospechosa. La respuesta de Elm no niega ninguna de esas premisas: ataca la conclusión desde otro ángulo.

Aquí está el núcleo del argumento, y es más sutil que la apelación habitual a la disciplina. Cuando un lenguaje ofrece una vía de escape, la garantía deja de ser una propiedad del lenguaje y se convierte en una propiedad del uso concreto que se hace de él. Para responder a la pregunta de si este programa puede romper en ejecución ya no basta con saber en qué lenguaje está escrito: hay que auditar el código propio, el de todas las dependencias y el de las dependencias de estas. La afirmación pasa de ser universal y verificable por construcción a ser particular y verificable por inspección, y la inspección no escala. Una sola escotilla en una biblioteca transitiva de la que nunca has oído hablar basta para que la propiedad deje de valer en todo el sistema.

flowchart TD
L[Lenguaje con escotilla] --> Q[La garantia depende del uso]
Q --> AU[Hay que auditar todo el arbol]
AU --> NE[La propiedad no escala]
E[Lenguaje sin escotilla] --> C[La garantia es del lenguaje]
C --> SA[No hace falta auditar nada]
SA --> ES[La propiedad se compone]
style E fill:#a6e3a1,color:#11111b
style L fill:#f38ba8,color:#11111b
style ES fill:#cba6f7,color:#11111b

Conviene ver la asimetría con números aproximados para que no quede en abstracción. Una aplicación mediana en un ecosistema de paquetes arrastra con facilidad varios centenares de dependencias transitivas escritas por cientos de personas distintas a lo largo de una década. Afirmar que ese conjunto no contiene ni una sola conversión insegura, ni un solo acceso a una propiedad que podría faltar, ni una sola excepción sin capturar, exigiría una auditoría que nadie ha hecho jamás y que caducaría con la siguiente actualización. La afirmación equivalente en Elm no requiere auditoría alguna, porque la propiedad no depende del contenido de los paquetes sino de que el compilador no admite ese contenido. Esa es la diferencia entre una garantía que se comprueba y una que se construye, y solo la segunda sobrevive al crecimiento del proyecto.

El segundo tramo del argumento es sociológico y explica por qué la disciplina no sustituye al diseño. Una escotilla es la vía más barata bajo presión, y la presión es la condición normal del trabajo. Cuando faltan dos horas para una entrega y el sistema de tipos se interpone, el tipo comodín no es una tentación sino la salida racional para ese individuo en ese momento; el coste de usarlo lo pagará otra persona en otro trimestre. Por eso las escotillas que se diseñan para casos excepcionales tienden estadísticamente a normalizarse, y por eso los equipos que las usan poco lo consiguen a base de reglas, revisiones y configuraciones adicionales, es decir, reconstruyendo con trabajo humano continuo la propiedad que el diseño podía haber regalado.

Conviene añadir que la propia existencia de la puerta cambia el diseño de las bibliotecas aunque nadie la use. Cuando un autor sabe que puede resolver un caso difícil con una vía de escape, el incentivo para encontrar una formulación que el sistema de tipos acepte se debilita, y el ecosistema acumula soluciones que funcionan sin ser expresables. Cuando esa puerta no existe, la dificultad se resuelve arriba, en el diseño del tipo, y el resultado queda disponible para todos. Esa presión constante hacia el modelado explica por qué la biblioteca de un lenguaje sin escotillas tiende a tener menos funciones y mejores tipos que la de un lenguaje comparable que sí las ofrece.

Dónde duele de verdad

Ser honesto con la decisión exige señalar los casos en los que la ausencia de escotillas produce un coste que ninguna válvula compensa. La abstracción sobre contenedores es el más citado: sin clases de tipos no se puede escribir una función genérica que funcione para cualquier estructura que admita un mapeo, y el resultado es repetición de código en cada módulo. La medición síncrona del documento es el segundo, porque hay interacciones —arrastrar, animar con posiciones calculadas, sincronizar desplazamientos— en las que un fotograma de retraso se percibe. El tercero es la exploración: probar una interfaz experimental del navegador exige montar la fontanería antes de saber siquiera si la idea vale. Un lenguaje que no ofrece atajos convierte el prototipado descuidado en algo caro, y el prototipado descuidado es a veces la herramienta correcta.

Queda una consideración final antes del argumento de fondo, y tiene que ver con quién paga el coste dentro de un equipo. La ausencia de escotillas redistribuye el trabajo: quien construye la frontera —los puertos, los decodificadores, los elementos personalizados— hace un esfuerzo concentrado y desagradable al principio del proyecto, mientras que quien escribe funcionalidad después trabaja en un entorno donde nada puede fallar de forma inesperada. Esa redistribución es políticamente incómoda porque el esfuerzo es visible y el beneficio es difuso, y explica buena parte del rechazo temprano de los equipos: el coste se paga en la primera semana y la recompensa llega en el segundo año, que es exactamente el reparto que peor toleran las organizaciones que miden por entregas.