As a genre, the “award acceptance lecture” is little more than a formality and a banality. But there is at least one charming exception to this rule—the talks given by the foremost computer scientists on the occasion of their Turing Awards.

Some read like manifestos: John Backus’ “Can Programming Be Liberated From the von Neumann Style?” (1977) inspired a new paradigm that begat functional languages like Haskell. Others are warnings: In his “Reflections on Trusting Trust” (1984), Ken Thompson demonstrated the peril of backdoored compilers, likely preventing scads of security vulnerabilities. Edsger Dijkstra, in “The Humble Programmer” (1972), urged his ilk to be wary of cleverness and acknowledge “the intrinsic limitations of the human mind.”

For our purposes, consider Kenneth Iverson’s heady 1979 lecture, “Notation as a Tool of Thought.” In it, he demonstrated that mathematical notations aren’t just convenient shorthand—CO₂ for carbon dioxide, 3,888 for MMMDCCCLXXXVIII—they also make new insights readily discoverable. As the mathematician Alfred North Whitehead once put it: “By relieving the brain of all unnecessary work, a good notation sets it free to concentrate on more advanced problems.”

Iverson won his Turing Award for APL, a spooky-looking programming language that began its life as a system of notation for bridging between languages. In the early days of scientific computing, programmers had to think in one language (mathematical notation) but then program in another (e.g., Fortran). APL was designed so that unwieldy operations could be written as compactly as equations—lines of code collapsed into a couple of symbols like + or ×. APL turned out to be more influential than adopted, but no matter: It showed that two languages could be fused into one.

The year 2026 marks 60 years since the introduction of APL, and a new kind of two-language problem bedevils the field of scientific computing. The ruling programming language is Python, but it reigns not as a muscular conqueror so much as a doddering king. Python, in other words, is terribly slow—a flaw that even its most ardent defenders would not deny.

Hence the two-language problem: Researchers prototype in slow, friendly Python but, for performance-critical parts, rewrite in faster, less friendly languages like C++ or Rust. This limitation can’t be solved by spinning up a platoon of AI coding agents, because no matter how much you optimize a slow language, a faster one will outperform it.

These binary trade-offs exist in other domains. You could say that construction, for instance, has a two-material problem. Wood is a pliable material for prototyping a structure—even an amateur can saw and nail together a functional building. But it’s no good for erecting a skyscraper. This raises an obvious question: What if there were a material as manipulable as wood but as strong as steel? What if there were a language as ergonomic as Python but as fast as C?

In 2012, four computer scientists with strong mathematical bona fides came together to address the modern-day two-language problem. In a short essay called “Why We Created Julia,” they said they took up the project “because we are greedy.” Their text begins like a valentine to programming languages:

We are power Matlab users. Some of us are Lisp hackers. Some are Pythonistas, others Rubyists, still others Perl hackers … We’ve generated more R plots than any sane person should. C is our desert island programming language.

But every one of these languages, they wrote, “is perfect for some aspects of the work and terrible for others.” Greedy as they were, they wanted “a language that’s open source, with a liberal license … Something that is dirt simple to learn, yet keeps the most serious hackers happy.” Julia would be the one language to unite them all.

I first encountered Julia by happenstance in 2017—a year before its syntax stabilized—when I attended lectures by Sebastian Seung, a neuroscientist who was using it to map connectomes, the complete map of neural pathways in the brain. My first impression was of its delightful, winsome name, which defied the clumsy nomenclature common in the field: the inelegant (PL/I), the ugly (Erlang), the typographically ungainly (C++), and the literally pathological (MUMPS—which, if you can believe it, forms the backbone of the American health care system).

I could also see that serious thought had gone into designing Julia. After studying the many pitfalls other languages had fallen into, the creators marshaled neat ideas from different languages—a testament to the fact that careful observation must come before embarking on so fine an enterprise as creating a new one.

As of 2026, Julia has come to attract a sober community of grown-ups—which can’t be said of many language communities. Language nerds are an emotional, clamorous bunch (many a friendship has been broken over a difference of opinion on syntax), but the Julia community has yet to be convulsed by any major drama. It leans academic, drawing scientists more than hackers. But unlike other languages also used by academics, Julia doesn’t get too fanciful (like Haskell), nor does it attract worshipful fans (also like Haskell) or engage in intellectual gamesmanship (like, say, Haskell). At the annual Julia-Con, you’ll hear triumphant stories of rewriting MATLAB code in Julia and gaining 60X speedups. By some benchmarks, Julia code can run 10X to 1,000X faster than Python.

But you won’t find Julia on Stack Overflow’s annual survey chart of the most popular languages. It didn’t replace Python, in the end—not even close. Why not? What went wrong?

First, just as a human language depends on the corpus of texts written in it, a programming language is only as good as its ecosystem and tooling. Python’s is far too robust to dislodge. Second, Julia has not been adopted by Big Tech. In the past, when a minor language was plucked from obscurity and rose to prominence, it was thanks to this kind of corporate patronage: Objective-C by Apple for iOS development, Kotlin by Google for Android development.

But third, and this is my answer: Nothing went wrong. Julia is a niche language, and for what it’s doing, it’s plenty successful. In all probability, Julia will live on, small but beloved. It is used for Herculean work at institutions like ASML, CERN, and NASA and in serious ventures like drug discovery and advanced machine learning.

Even if Julia does replace Python someday, I’m not convinced it can solve the two-language problem—or that any language can. While the problem is commonly referenced in scientific computing, it exists in every software domain. In gaming, engines are written in C++ but scripted in Lua. In server backends, there is a panoply of easier languages—Python, Ruby, JavaScript—but when real performance is needed, the work is done in Go or Rust. Conversely, valiant efforts to use Go or Rust for frontend development have utterly failed.

But who am I to say we’ll be stuck here forever? Perhaps one day someone as insightful as Iverson will figure out how to bridge the gap once and for all. When that happens, make sure to tune in to their Turing lecture.

This is the second installment in a three-part Machine Readable series on AI-enabling languages.