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—CO2 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.