Como género, el “discurso de aceptación de un premio” no es más que una formalidad y una banalidad. Pero hay al menos una excepción encantadora a esta regla: las charlas que imparten los informáticos más destacados con motivo de la entrega de sus Premios Turing.
Algunas se leen como manifiestos. “¿Puede la programación liberarse del estilo de von Neumann?” (1977), de John Backus, inspiró un nuevo paradigma que dio lugar a lenguajes funcionales como Haskell. Otras son advertencias. En “Reflections on Trusting Trust” (Reflexiones sobre la confianza) (1984), Ken Thompson puso de manifiesto el peligro de los compiladores con puertas traseras, lo que probablemente evitó un sinfín de vulnerabilidades de seguridad. Edsger Dijkstra, en “The Humble Programmer” (El programador humilde) (1972), instó a sus compañeros a desconfiar de la astucia y a reconocer “las limitaciones intrínsecas de la mente humana”.
A efectos de este artículo, consideremos la estimulante conferencia de Kenneth Iverson de 1979, “Notation as a Tool of Thought” (La notación como herramienta de pensamiento). En ella demostró que las notaciones matemáticas no son solo una forma abreviada y práctica (CO₂ para dióxido de carbono, 3,888 para MMMDCCCLXXXVIII) sino que también facilitan el descubrimiento de nuevas perspectivas. Como dijo en su día el matemático Alfred North Whitehead: “Al liberar al cerebro de todo trabajo innecesario, una buena notación le permite concentrarse en problemas más avanzados”.
Iverson ganó su Premio Turing por APL, un lenguaje de programación de aspecto enigmático que comenzó su vida como un sistema de notación destinado a tender puentes entre lenguajes. En los inicios de la informática científica, los programadores tenían que pensar en un lenguaje (la notación matemática) pero luego programar en otro (por ejemplo, Fortran). APL se diseñó para que las operaciones complejas pudieran escribirse de forma tan compacta como las ecuaciones: líneas de código reducidas a un par de símbolos como + o ×. APL resultó tener más influencia de la que se le atribuyó, pero no importa: demostró que dos lenguajes podían fusionarse en uno solo.
Qué es el problema de los dos lenguajes
El año 2026 marca el 60 aniversario de la introducción de APL, y un nuevo tipo de problema relacionado con los dos lenguajes está causando estragos en el campo de la informática científica. El lenguaje de programación dominante es Python, pero no reina como un conquistador poderoso sino más bien como un rey senil. Python, en otras palabras, es terriblemente lento (un defecto que ni siquiera sus defensores más acérrimos negarían).
De ahí el problema de los dos lenguajes: los investigadores crean prototipos en Python, lento pero fácil de usar, pero, para las partes en las que el rendimiento es fundamental, reescriben el código en lenguajes más rápidos y menos intuitivos, como C++ o Rust. Esta limitación no se puede resolver creando un batallón de agentes de programación basados en IA, porque, por mucho que se optimice un lenguaje lento, uno más rápido siempre lo superará en rendimiento.
Estas disyuntivas binarias existen en otros ámbitos. Se podría decir que la construcción, por ejemplo, tiene un problema de dos materiales. La madera es un material maleable para crear prototipos de estructuras; incluso un aficionado puede serrar y clavar para construir un edificio funcional. Pero no sirve para levantar un rascacielos. Esto plantea una pregunta obvia: ¿y si existiera un material tan fácil de manipular como la madera, pero tan resistente como el acero? ¿Y si existiera un lenguaje tan ergonómico como Python, pero tan rápido como C?
En 2012, cuatro informáticos con una sólida formación matemática se unieron para abordar el problema actual de los dos lenguajes. En un breve ensayo titulado “Por qué creamos Julia”, afirmaron que emprendieron el proyecto “porque somos codiciosos”. Su texto comienza como una declaración de amor a los lenguajes de programación:
