Can Any Programming Language Truly Bridge the Two-Language Divide?

Nearly every standard award acceptance speech reads as a predictable, polite, and instantly forgettable exercise in formality. But there is one exceptional category that consistently rises far above this low bar: the landmark lectures delivered by preeminent computer scientists upon receiving the A.M. Turing Award, the field’s highest honor.

Some of these addresses read like paradigm-shifting manifestos: John Backus’ 1977 talk Can Programming Be Liberated From the von Neumann Style? laid the conceptual foundation for functional programming, spurring the creation of languages like Haskell. Others act as urgent, prescient warnings: Ken Thompson’s 1984 Reflections on Trusting Trust exposed the existential risk of backdoored compilers, saving countless systems from catastrophic unpatched security flaws. Edsger Dijkstra used his 1972 address The Humble Programmer to urge his fellow engineers to prioritize humility over flashy cleverness, and confront the inherent limits of human cognitive capacity.

For anyone invested in how language design shapes the way we interact with computation, the most compelling of these lectures is Kenneth Iverson’s sharp, rigorous 1979 talk Notation as a Tool of Thought. Iverson argued that mathematical notation is far more than a convenient shorthand (like using CO₂ for carbon dioxide, or condensing MMMDCCCLXXXVIII to 3888): it actively lowers barriers to counterintuitive, previously unobtainable insights. As mathematician and philosopher Alfred North Whitehead put it decades earlier: “By relieving the brain of all unnecessary work, a good notation sets it free to concentrate on more advanced problems.”

Iverson earned his Turing Award for APL, a famously idiosyncratic programming language that originated as a formal notation system built to solve a pervasive pain point of early scientific computing: the first “two-language problem.” Back then, researchers would map out their logic using familiar mathematical notation, then be forced to rebuild that entire structure from scratch in a completely separate, far less intuitive language such as Fortran. APL was designed to collapse that gap, letting users write complex, unwieldy operations as concisely as a mathematical equation, tucking sprawling lines of procedural code into a handful of dense, purpose-built symbols like + or ×. Though APL never achieved mainstream mass adoption, its influence rippled across the entire field: it proved definitively that you could merge the language of mathematics and the language of computers into a single, cohesive system.

2026 marks 60 years since APL first launched, and a new, far more widespread iteration of that old two-language problem now plagues modern scientific computing. The de facto dominant language of the field today is Python — but it rules not as a dynamic, conquering emperor, but as a slow, creaking monarch. Even its most diehard defenders cannot deny its core flaw: it is exceptionally slow to execute. That creates a familiar, frustrating compromise: researchers prototype their work quickly in approachable, human-friendly Python, then have to manually rewrite all performance-critical sections in far more verbose, harder to master low-level languages like C++ or Rust. No number of AI code generation assistants can fully eliminate this tradeoff: you can only optimize a slow interpreted language so far, before a purpose-built fast compiled one will outrun it by orders of magnitude.

This kind of forced dual-system compromise crops up everywhere, far outside of software development. Take construction, for example: the industry faces its own “two-material problem.” Wood is lightweight, flexible, and approachable enough that even an amateur hobbyist can saw and nail it into a fully functional small structure. But it is completely unsuited to building skyscrapers, which require the unmatched tensile strength of steel. That leads to an obvious, almost tantalizing question: what if we had a material that was as easy to shape as wood, but as strong as steel? What if we had a programming language that was as intuitive and forgiving as Python, but as fast as C?

In 2012, four computer scientists with deep, well-established backgrounds in mathematics set out to answer that exact question, to solve the modern two-language problem once and for all. In their short founding essay Why We Created Julia, they open with a warm, unapologetic line: they took on the project “because we are greedy.” The text reads like a love letter to the best parts of existing 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 those tools, they wrote, “is perfect for some aspects of the work and terrible for others.” Driven by that greed, they set out to build something that checked every box: open source with a permissive license, simple enough for beginners to pick up quickly, but powerful and expressive enough to keep even the most veteran, hardcore engineers fully satisfied. That language was Julia, designed to unite all those disparate ecosystems in one place.

I first stumbled on Julia completely by chance in 2017, a full year before its syntax was finalized and stabilized, when I attended a series of talks by neuroscientist Sebastian Seung, who was using the language to map connectomes — the full, intricate web of neural pathways inside the human brain. My first reaction to the language was delight at its gentle, approachable name, a refreshing break from the clumsy, often unappealing naming conventions common in programming language history: the clunky PL/I, the harsh-sounding Erlang, the typographically messy C++, and the unhinged-sounding MUMPS, which (unbelievably) powers the core infrastructure of most of the U.S. healthcare system.

It was immediately clear that Julia’s design was the product of extremely careful, thoughtful planning. Its creators had spent years studying every pitfall, flaw, and blind spot that tripped up earlier languages, then curated the strongest, most elegant ideas from across decades of language design — proof that deliberate, observation-led research is the only path to building something that ambitious and well-crafted.

By 2026, Julia has cultivated a remarkably mature, low-drama community, a rarity in the often fractious world of programming language fandom. Language enthusiasts are famously passionate, even combative: countless friendships have dissolved over petty disagreements about syntax or best practices, but the Julia community has never been roiled by the massive public drama that has engulfed communities for other popular languages. It skews heavily academic, drawing far more working scientists than hobbyist hackers, and unlike other research-focused languages it never drifts into unapproachable, overly academic gimmickry (a common pitfall for Haskell), nor does it attract cult-like worshippers, or devolve into performative intellectual one-upmanship. At the annual JuliaCon conference, attendees regularly share success stories of porting old MATLAB code to Julia and seeing immediate 60x speedups. Independent benchmarks show Julia can run anywhere from 10x to 1000x faster than equivalent Python code.

And yet, you will not find Julia high on Stack Overflow’s annual list of the world’s most popular programming languages. It never came close to dethroning Python, as many early boosters predicted it would. Why? What stopped it from reaching mass adoption?

Three key factors stand out. First, just as a spoken human language lives or dies by the body of text written in it, a programming language is only as strong as its supporting ecosystem and tooling — and Python’s ecosystem is so vast, robust, and well-established that no new challenger could reasonably displace it any time soon. Second, Julia never landed the high-profile corporate backing that catapulted other niche languages to mainstream fame: Apple plucked Objective-C from obscurity to power iOS app development, Google adopted Kotlin as the official language for Android, but no big tech giant ever threw its full weight behind Julia.

But third, and most importantly: nothing “went wrong” at all. Julia is thriving as a specialized, high-impact niche language, and it has already exceeded every reasonable metric of success for that use case. It will almost certainly persist for decades to come, small but fiercely beloved by its core user base. It powers heavy-duty, mission-critical work at institutions including ASML, CERN, and NASA, and is used extensively for cutting-edge work in drug discovery and next-generation machine learning research.

Even if Julia somehow does overtake Python someday, I remain skeptical that it — or any single language — can fully eliminate the two-language problem. The divide is far more universal than most people realize, present in every single corner of software development, not just scientific computing. Game development uses high-performance C++ for core engine code, but lightweight, accessible Lua for in-game scripting. Server backends rely on easy-to-work-with languages like Python, Ruby, and JavaScript for most logic, but shift performance-critical workloads to Go or Rust. Conversely, numerous well-funded attempts to build frontend web interfaces in Go or Rust have all failed to gain any meaningful traction.

That said, I would never claim that we are stuck with this tradeoff forever. One day, a computer scientist with the same rare clarity of vision as Kenneth Iverson may crack the puzzle, and build a notation that bridges that final gap once and for all. When that day comes, be sure to tune into their Turing Award acceptance lecture.

---

This is the second installment of a three-part series in the Machine Readable collection, exploring programming languages that power the modern AI ecosystem.