As a species, the “award acceptance lecture” is little more than formality and cliché. However, there is at least one charming exception to this rule – lectures given by leading computer scientists on their holiday Turing Awards.
Some sound like manifestos: “John Backus”Is it possible to liberate programming from von Neumann’s style?(1977) inspired a novel paradigm that gave rise to functional languages such as Haskell. Others are warnings: In his “Reflections on trust(1984) Ken Thompson demonstrated the danger of backdoor compilers, possibly preventing a number of security vulnerabilities. Edsger Dijkstra, in “A humble programmer(1972) urged people to eschew cleverness and acknowledge the “intrinsic limitations of the human mind.”
For our purposes, consider a powerful lecture by Kenneth Iverson from 1979:Notation as a thinking tool” He showed that mathematical notations are not just a convenient shortcut – CO2 for carbon dioxide, 3888 for MMMDCCCLXXXVIII – they also allow you to easily discover novel insights. As the mathematician Alfred North Whitehead once put it, “By relieving the brain of all unnecessary work, good writing allows it to concentrate on more advanced problems.”
Iverson won a Turing Award for APL, a spooky-looking programming language that began life as a notation system for combining languages. In the early days of scientific computing, programmers had to think in one language (mathematical notation) and then program in another (e.g. Fortran). APL is designed so that cumbersome operations can be written as concisely as equations – lines of code collapsed into a few symbols, e.g. + Or ×. APL proved more influential than adopted, but it didn’t matter: it showed that two languages could be combined into one.
The year 2026 It’s been 60 years since APL was introduced, and a novel kind of bilingual problem is plaguing the field of scientific computing. The ruling programming language is Python, but it reigns less as a muscular conqueror than as a trembling king. In other words, Python is terribly sluggish – a flaw that even its most ardent defenders cannot deny.
Hence the dual-language problem: researchers create prototypes in the sluggish, warm language Python, but for performance-critical parts they rewrite them in faster, less warm languages such as C++ or Rust. This limitation cannot be solved by creating a platoon of AI coding agents, because no matter how much you optimize a sluggish language, a faster one will outperform it.
These binary trade-offs exist in other areas. It can be said that in construction, for example, there is a dual-material problem. Wood is a elastic material for prototyping structures – even an amateur can cut and assemble a functional building. But it’s not good for building a skyscraper. An obvious question arises: what if there was a material as straightforward to work with as wood, but as forceful as steel? What if there was a language as ergonomic as Python but as rapid as C?
In 2012, four computer scientists with forceful mathematical bona fides have come together to address the current two-language problem. In a tiny essay entitled “Why we created Julia”, they said they took on this project “because we are greedy”. Their text begins as a Valentine for programming languages:
We are advanced Matlab users. Some of us are Lisp hackers. Some are Pythonists, some are Rubyists, and some are Perl hackers… We have generated more R graphs than any reasonable person should. C is our programming language on a desert island.
But each of these languages, they wrote, “is perfect at some aspects of work and terrible at others.” As greedy as they were, they wanted “an open-source language with a liberal license… Something that was straightforward to learn and would still make even the biggest hackers joyful.” Julia would be the only language that would unite them all.