Python es terriblemente lento. ¿Podrá Julia resolver el “problema de los dos lenguajes”?

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:

Somos usuarios avanzados de Matlab. Algunos de nosotros somos hackers de Lisp. Algunos somos “Pythonistas”, otros “Rubyistas”, y otros hackers de Perl… Hemos generado más gráficos de R de los que cualquier persona en su sano juicio debería. C es nuestro lenguaje de programación preferido.

Pero cada uno de estos lenguajes, escribieron, “es perfecto para algunos aspectos del trabajo y terrible para otros”. Codiciosos como eran, querían “un lenguaje de código abierto, con una licencia liberal… Algo que sea tremendamente sencillo de aprender, pero que mantenga contentos a los programadores más exigentes”. Julia sería el único lenguaje capaz de unirlos a todos.

¿Un lenguaje unificador?

Descubrí Julia por casualidad en 2017 (un año antes de que se estabilizara su sintaxis) cuando asistí a unas conferencias de Sebastian Seung, un neurocientífico que lo utilizaba para cartografiar conectomas, el mapa completo de las vías neuronales del cerebro. Mi primera impresión fue su nombre encantador y atractivo, que se alejaba de la torpe nomenclatura habitual en el campo: los poco elegantes (PL/I), los feos (Erlang), los tipográficamente desgarbados (C++) y los literalmente patológicos (MUMPS, que, aunque parezca increíble, constituye la columna vertebral del sistema sanitario estadounidense).

También pude apreciar que se había reflexionado seriamente sobre el diseño de Julia. Tras estudiar los numerosos problemas en los que habían caído otros lenguajes, los creadores reunieron ideas ingeniosas de diferentes lenguajes (una prueba de que la observación cuidadosa debe preceder a la puesta en marcha de una empresa tan ambiciosa como la creación de uno nuevo).

En 2026, Julia ha llegado a atraer a una comunidad sensata de adultos, algo que no puede decirse de muchas comunidades de lenguajes. Los fanáticos de los lenguajes son un grupo emocional y ruidoso (más de una amistad se ha roto por una diferencia de opinión sobre la sintaxis), pero la comunidad de Julia aún no se ha visto sacudida por ningún drama importante. Tiene un carácter más bien académico, y atrae más a científicos que a hackers. Pero, a diferencia de otros lenguajes que también utilizan los académicos, Julia no se vuelve demasiado fantasioso, tampoco atrae a seguidores fervientes ni se dedica a juegos intelectuales (como, por ejemplo, Haskell). En el Julia-Con anual, escucharás historias triunfales sobre cómo se ha reescrito código de MATLAB en Julia y se ha conseguido una aceleración de 60 veces. Según algunas pruebas de rendimiento, el código de Julia puede ejecutarse entre 10 y 1,000 veces más rápido que el de Python.

Pero no encontrarás a Julia en la tabla de la encuesta anual de Stack Overflow sobre los lenguajes más populares. Al final, no sustituyó a Python, ni de lejos. ¿Por qué no? ¿Qué salió mal?

En primer lugar, al igual que un idioma humano depende del corpus de textos escritos en él, un lenguaje de programación es tan bueno como su ecosistema y sus herramientas. El de Python es demasiado sólido como para desbancarlo. En segundo lugar, Julia no ha sido adoptado por las grandes empresas tecnológicas. En el pasado, cuando un lenguaje menor salía del anonimato y alcanzaba la fama, era gracias a este tipo de patrocinio corporativo: Objective-C por parte de Apple para el desarrollo de iOS, Kotlin por parte de Google para el desarrollo de Android.

Y en tercer lugar, y esta es mi respuesta: no ha pasado nada malo. Julia es un lenguaje de nicho y, para lo que hace, tiene mucho éxito. Con toda probabilidad, Julia seguirá existiendo, pequeño pero querido. Se utiliza para tareas titánicas en instituciones como ASML, el CERN y la NASA, y en proyectos serios como el descubrimiento de fármacos y el aprendizaje automático avanzado.

Incluso si Julia llegara a sustituir a Python algún día, no estoy convencido de que pueda resolver el problema de los dos lenguajes (ni de que ningún lenguaje pueda hacerlo). Aunque este problema se menciona habitualmente en la informática científica, existe en todos los ámbitos del software. En los videojuegos, los motores se escriben en C++, pero los scripts se programan en Lua. En los backends de los servidores hay toda una panoplia de lenguajes más sencillos (Python, Ruby, JavaScript), pero cuando se necesita un rendimiento real, el trabajo se realiza en Go o Rust. Por el contrario, los valientes esfuerzos por utilizar Go o Rust para el desarrollo frontend han fracasado estrepitosamente.

Ahora, ¿quién soy yo para decir que nos quedaremos estancados aquí para siempre? Quizá algún día alguien tan perspicaz como Iverson descubra cómo salvar esa brecha de una vez por todas. Cuando eso ocurra, asegúrate de escuchar su conferencia Turing.

Artículo originalmente publicado en WIRED. Adaptado por Andrea Baranenko.