Phillip Mortimer analiza la complejidad y la escritura de código inmutable en ingeniería de software
En una charla, Mortimer muestra el famoso J Incunabulum y discute cómo la densidad del código afecta la mantenibilidad, especialmente en la era de la IA.
Phillip Mortimer abrió su presentación con el J Incunabulum, una pieza de código C escrita en una tarde de 1989 por Arthur Whitney. Ese fragmento, de unas pocas líneas, implementa un intérprete completo del lenguaje J, con modelo de objetos, gestión de memoria, parser, lexer y REPL. La densidad del código lo convierte en un ejemplo clásico de write‑only software: funciona, pero es prácticamente imposible de leer o modificar.
Mortimer citó a Eric S. Raymond, quien define el código write‑only como aquel tan arcano o mal estructurado que solo su autor puede comprenderlo, y a veces ni siquiera él. Como ejemplos, mencionó APL, creado por Ken Iverson en 1962, y las expresiones regulares. En APL mostró una única expresión que implementa una generación de Conway's Game of Life en una matriz booleana, equivalente a 40‑50 líneas en otros lenguajes. En regex presentó una validación de fechas MM/DD/YYYY que cubre todos los años del 0 al 9999, incluyendo reglas de años bisiestos, todo sin código procedural.
El ponente explicó que, aunque el código sea compacto y potente, su mantenibilidad sufre. Propuso dos principios para manejar esta complejidad: las pruebas como documentación y el código descartable. Cuando el código es tan denso que no se puede depurar, la única forma fiable de entender su comportamiento es a través de casos de prueba que describen entrada‑salida. Además, si la depuración resulta inviable, a menudo es más rápido reescribir el módulo desde cero, conservando las pruebas como contrato.
Mortimer también relacionó su experiencia personal: trabajó en Morgan Stanley con A+ (derivado de APL) y, tras dejar la firma, desarrolló soluciones de inteligencia documental en la startup Accelex, donde dependía mucho de regex. Concluyó que la tentación de usar soluciones write‑only genera más problemas de los que resuelve, una observación respaldada por la frase de Jamie Zawinski: “Algunas personas, al enfrentarse a un problema, piensan ‘usaré expresiones regulares’. Ahora tienen dos problemas”.
