Niklaus Wirth and the virtue of small programs

The first compiler I ever thought of as mine was Turbo Pascal, on a DOS machine, sometime in the early ’90s. I didn’t know it was unusual. You typed, you pressed a key, and the program was built before you’d finished moving your hand off the keyboard. The first versions, editor and compiler together, were one .COM file of around 40KB. The one I used was bigger than that, but still fast enough that I never once waited for it. I later spent a lot of years in Visual Studio, which takes longer to show its splash screen.

Niklaus Wirth, who designed Pascal, died on January 1st, at 89. Bertrand Meyer posted the news on the 3rd, and Hacker News spent most of that day sharing memories of Pascal, Modula-2 and Oberon, and of being taught, one way or another, by someone who’d learned from him. Kent Beck wrote a nice remembrance the next day.

The list of what he did is long enough that it’s easy to read as a list. Euler and Algol W in the ’60s. Pascal in 1970, meant as a language for teaching structured programming, which escaped and became the language a lot of real software was written in for twenty years. Modula-2. Oberon, the language and the whole operating system written in it, with Jürg Gutknecht, small enough that the two of them could describe every line of it in one book. The Lilith workstation, built at ETH after he’d seen the Alto at Xerox PARC. Algorithms + Data Structures = Programs, which is the best title a programming book has ever had. The Turing Award in 1984.

There’s also a line through my own career I’d never really traced until this week. Turbo Pascal was written by Anders Hejlsberg. Hejlsberg went on to do Delphi, then went to Microsoft and became the lead architect of C#, which is the language I spent my MVP years writing and arguing about. A lot of what felt clean about C# compared to C++ (a real type system, a compiler that’s fast and strict and tells you exactly what’s wrong) has Pascal somewhere in its family tree. I wrote Pascal for maybe two years and C# for twenty, and I think Wirth shaped both of those more than I gave him credit for.

The plea

The thing of his I’ve reread most is a short essay from 1995 in IEEE Computer called “A Plea for Lean Software”. It’s where the line people now call Wirth’s law comes from, though he credits it to Martin Reiser: software gets slower faster than hardware gets faster. The essay’s argument is that this isn’t a law of nature, it’s a choice. Vendors add every feature anyone asks for, nobody takes anything out, and the cost lands on users as bigger machines they have to buy. Oberon was his proof that it didn’t have to be like that.

In 1995 that was a slightly cranky thing to say. In 2024 I think it’s just a description. The chat app on my laptop is using a bit over a gigabyte of memory right now to show me text messages. Our main web app’s node_modules folder has about 48,000 files in it. We have a small internal admin tool, maybe 3,000 lines of our own code, that pulls in a framework, an ORM, two date libraries (nobody knows why there are two), and takes about four minutes to build in CI. None of those things is wrong on its own, and I approved most of them. That’s sort of his point.

What I take from him isn’t “write everything in Oberon”. It’s the habit of asking whether a thing could be understood by one person, and treating “no” as a problem, not a fact about modern software. One of the rules in the essay, roughly, is that a system nobody can understand in detail probably shouldn’t be built. I’ve watched teams, mine included, cross that line without noticing, one reasonable dependency at a time, and I don’t know how you’d notice in the moment. Left-pad was one of the times it got noticed for us.

He kept working on Oberon into his eighties, and he redid the Project Oberon book in 2013 for a new machine built on an FPGA. I find that more inspiring than any of the awards. Nearly eighty and still trying to make the whole system fit in one head.