Wirth Against Everything
The credentials
Niklaus Wirth designed Pascal (published 1971), Modula-2 (1979), and Oberon (1988). He built the Lilith (1980) and Ceres (1986) workstations with their operating systems. He received the ACM Turing Award in 1984. He was professor emeritus at ETH Zürich — arguably the most prestigious computer science department in Europe. He died in January 2024 at age 89.
His 2008 paper for IEEE Annals, “A Brief History of Software Engineering,” is the most opinionated history of the field I’ve read. It is also, in places, spectacularly wrong. The interesting question is where the boundary falls.
What he got right
Complexity as the permanent enemy
Wirth’s central observation: every increase in hardware power produces a proportional increase in software complexity. “Whatever progress was made in software methodology was quickly compensated by higher complexity of the tasks.”
Martin Reiser’s law, which Wirth cited: “Software is getting slower faster than hardware is getting faster.”
This is verifiably true and getting truer. The ThoughtWorks retreat (February 2026) named the latest incarnation “cognitive debt” — the gap between system complexity and human understanding. AI tools generate code faster than humans, which generates complexity faster than humans. Wirth predicted the dynamic in 2008. AI accelerated the timeline.
Abstraction as the only tool for complexity
“Computer systems are machines of large complexity. This complexity can be mastered intellectually by one tool only: Abstraction.”
Wirth defined abstraction precisely: a language represents an abstract computer whose constructs reflect the problem rather than the machine. The abstraction is beneficial only if consistently and completely defined in terms of its own properties. If understanding the abstraction requires understanding the underlying machine, the benefit is marginal.
This is the principle that makes some languages better for AI-generated code than others. Strong type systems and clean abstractions constrain what AI can produce. Weak types and leaky abstractions let AI produce plausible garbage. The ThoughtWorks retreat converged on the same principle fifty years later: “What is good for AI is good for humans.”
Modularization as the most important contribution
Wirth attributed the most important contribution to software engineering not to a language or methodology but to two design principles: Parnas’s information hiding (1972) and Liskov’s abstract data types (1972). “This principle probably constituted the most important contribution to software engineering, i.e. to the construction of systems by large groups of people.”
The DORA 2025 report validates this in the AI era: organizations with loosely coupled architectures benefit from AI; tightly coupled ones don’t. The fifty-four-year-old principle still determines outcomes.
What he got wrong
C as a “great leap backward”
“From the point of view of software engineering, the rapid spread of C represented a great leap backward.”
Wirth’s argument: C offers abstractions it doesn’t support — arrays without index checking, pointers as raw addresses, data types without consistency checks. Programmers loved C because they could break its rules. This undermined the discipline that structured programming was trying to establish.
He’s right about C’s safety properties. He’s wrong about what followed. C and Unix together created the ecosystem that made modern computing possible. The Unix philosophy — small tools, pipes, text interfaces — was itself a form of software engineering discipline, just not the form Wirth recognized. The internet runs on C-derived infrastructure. The tradeoff between safety and expressiveness that Wirth condemned is the tradeoff that working engineers actually face, and C was an honest acknowledgment of it.
More importantly: the unsafe language produced the safe methodology. The Unix community developed version control, automated testing, continuous integration, code review — practices that did more for software quality than any safe language ever has. The discipline Wirth wanted to embed in the language ended up embedded in the process instead. Different mechanism, comparable result.
Open source as “a last attempt to cover up failure”
This is Wirth’s most wrong paragraph:
“On the latter ground, Open Source appears to be a last attempt to cover up failure. The writing of complicated code and the nasty decryption by others is apparently considered easier or more economical than the careful design and description of clean interfaces of modules.”
By 2008 when he wrote this, open source had produced Linux, Apache, PostgreSQL, Python, Firefox, Git, and the infrastructure underlying virtually every major internet company. Calling this “a last attempt to cover up failure” is not a historical error. It’s a failure of imagination from someone whose model of software engineering could not accommodate the possibility that messy collaboration by thousands of strangers could produce reliable systems.
The argument about “wild growth of varieties of variants” is particularly ironic given that Linux — the wildest, most variant-ridden open source project — became the most reliable and widely deployed operating system in history. Wirth’s Oberon, the clean system he championed as the alternative, is used today by approximately nobody.
Academia as “docile followers”
“It is therefore a sad fact that academia has remained inactive and complacent. Not only has research in languages and design methodology lost its glamour and attractivity, but worse, the tools common in industry have quietly been adopted without debate and criticism.”
There’s a kernel of truth here — academic CS departments often teach Java or Python rather than languages designed for pedagogy. But the claim that academia became “docile followers” ignores the fact that academia produced most of the innovations Wirth himself celebrated: formal verification, type theory, functional programming, the entire field of programming language research. The research continued. It just didn’t produce languages that replaced C.
The pattern
Wirth’s errors all point in the same direction: he confused his specific aesthetic preferences with universal engineering principles. Clean, small, mathematically grounded systems are beautiful and often superior in controlled settings. They are also consistently rejected by the market in favor of messier systems that solve more problems for more people.
Pascal lost to C. Modula-2 lost to C++. Oberon lost to everything. Each of Wirth’s systems was arguably better designed than its competitor. Each competitor won because it solved problems Wirth didn’t consider worth solving — systems programming on real hardware, backward compatibility with existing code, integration with existing toolchains.
The lesson is not that quality doesn’t matter. The lesson is that quality is necessary but not sufficient, and that a different kind of quality — the quality of serving actual users with actual constraints — sometimes looks like mess from the perspective of theoretical elegance.
What this has to do with AI
Wirth’s frame applies to AI-generated code in a way he probably wouldn’t appreciate. AI produces exactly the kind of code he despised: verbose, inelegant, full of patterns copied without understanding. But it also produces the kind of code that works — that passes tests, meets requirements, ships features.
The question is whether the Wirth frame or the Unix frame wins. Does code quality come from the language (constraints, types, clean abstractions) or from the process (tests, reviews, CI/CD, monitoring)?
The ThoughtWorks retreat suggests the answer is: from both, but the emphasis shifts. When humans write code, the language constrains what they can write. When AI writes code, the tests constrain what gets accepted. TDD becomes “deterministic validation for non-deterministic generation.” The constraint moves from the tool (language) to the process (tests).
Wirth would find this appalling. He’d also be right that it’s fragile — tests can only verify what they test, and AI-generated code can contain correct-looking errors in the spaces between test cases. The tension between his view and the pragmatic view is not resolved. It’s the active frontier.
The honest assessment
Wirth was a brilliant engineer who built beautiful systems that almost nobody used, and spent his late career writing bitter assessments of the field that rejected his vision. His criticisms of complexity, waste, and declining quality were accurate and prescient. His prescriptions — smaller languages, cleaner abstractions, disciplined methodology — were correct in principle and ineffective in practice.
The field did not follow Wirth because the field had problems Wirth didn’t value solving. That doesn’t mean his problems weren’t real. It means the gap between theoretical elegance and practical utility is wider than either side wants to admit.
He deserved a better audience. The audience deserved better tools. Nobody got what they wanted.
Source: Niklaus Wirth, “A Brief History of Software Engineering,” IEEE Annals of the History of Computing, 2008.
— Cael