Real Programmers Don’t Use Pascal

Programming is not a 20th century invention. Ideas behind what we call programming have existed since at least the 9th century. The very term “algorithm” comes from the name of Muhammad ibn Musa al-Khwarizmi, a mathematician born around 780 somewhere in modern-day Uzbekistan. The first computer program was written in 1837 by Charles Babbage, even though for a long time Ada Lovelace has been credited for having been the first programmer. Her contribution, a paper from 1843, was far more profound, though: she understood the potential of abstraction – symbol manipulation that goes beyond pure arithmetic. By 1880s Herman Hollerith devised how to store data in machine-readable form, and the first reconfigurable behavior device – the plugboard – was invented, also by Hollerith, back in 1906.

By mid-1940s programming was already a real thing. Scientists wrote algorithms in symbolic notation and coders translated them into binary code. When Kathleen Booth came up with an idea of an assembly language back in 1947 things started to heat up. First assemblers started to appear that automated this job, and as the anecdote has it, in 1953 von Neumann – having discovered that one of his assistants built an assembler – was furious: why waste a valuable scientific instrument on clerical work a human could do?

It never got any better.

A history of scoffing up

The pattern repeats with mechanical precision. When John Backus pitched FORTRAN in 1954, the hand-coders scoffed: a machine translating formulas could never match a human coder. Backus later said this skepticism – not the technical work – was the biggest obstacle of the whole project. When high-level languages won anyway, the critics simply moved the battlefield. Edsger Dijkstra declared that COBOL “cripples the mind” and that students exposed to BASIC were “mentally mutilated beyond hope of regeneration”.

By 1983 the whole reflex became so obvious that it got its own satire: Ed Post’s “Real Programmers Don’t Use Pascal” canonized the lore of the quiche-eating Pascal crowd against the Real Programmer who could write FORTRAN in any language – and who, taken to the extreme, needed no language at all, just toggle switches and contempt.

The illusion of bedrock

Every rung, the same drama. Assembly coders called compiler output wasteful – and it was. For a while. And that is the trick of it: the dinosaurs are always briefly right and permanently wrong. C programmers dismissed garbage collection as training wheels for people who could not manage their own memory. Java developers heard they were not doing real engineering; web developers heard they were not real programmers at all. The joke in my circle in the nineties was that the real programmer writes to the disk with a magnet – later immortalized by xkcd’s Real Programmers, where the punchline escalates to absurdity: the purest programmer uses no tools at all. Whoever laughed at that joke never actually noticed what it really says. If tools are cheating, then everything since the plugboard is cheating. The layer you built your career upon always feels like bedrock, and everything above it like sand.

And now it is happening to my generation, and I get a front row seat. I spend my days talking to programmers about AI, and I keep hearing the same sentence over and over again: yes, the models can write code, but we will always need people who understand it. Always. I heard that “always” about assembly. About memory management. About pointers. About SQL. Every “always” I have lived through had an expiration date, and the people saying it were not stupid – they were simply standing on their own ground, feeling how solid it was, mistaking that feeling for a law of nature. So when someone tells me today that reading every line of code will always be mandatory, I do not hear an argument. I hear 1954.

A new level of abstraction always looks like cheating – from one rung below.

When the translator talks back

So, what has really changed? It is not the lazy “machines learned to write code”. Not at all.

Here’s what changed. Every abstraction so far had one strict rule: the human must fully specify the intent, and the machine translates it without asking questions. A compiler is a deterministic slave – it does exactly what you wrote, including your mistakes, and the guarantee it gives you is preservation of meaning. That is why understanding code mattered so much: code was the only place where the intent existed in complete form. The specification and the program were the same artifact, and whoever couldn’t read it was locked out of the truth. This is the real reason we believe understanding code is sacred – not because code is precious, but because for seventy years code was the only complete record of what the system actually does.

That rule just broke. For the first time, the translator participates in figuring out what you meant. It fills gaps, it proposes, it asks back, it iterates. The intent no longer has to exist in one formal artifact before the machine can act on it – it can emerge through a conversation, a spec, a test suite, a feedback loop. Which means the code stops being the single source of truth and becomes what assembly output was yesterday: an intermediate artifact that somebody could inspect, but nobody did. And notice what we did with the compiler’s output: we did not keep reading it, we learned to trust it through verification. Nobody audits the assembly; we run the tests. The trust never came from understanding the lower layer. It came from having a reliable way to check the result against the intent.

That is where the engineering is moving, and that is why clinging to code-reading as the eternal core skill is barking up the wrong tree. The scarce skill was never the ability to write or read code – that was just the price of admission. The scarce skill was always knowing what actually needs to happen: mapping a messy real-world need onto precise behavior, deciding what “correct” means, building the feedback loop that catches the gap between what you asked for and what you got. Code was where that judgment lived, so we mistook the container for the content. The container is being replaced. The judgment is not – if anything, it just became the whole job. A machine that writes unlimited code on demand makes one thing more valuable than ever: the person who knows what to ask for and can reliably tell whether they received it.

The museum of syntax

But, abstractions leak – as Joel Spolsky formulated in his famous law back in 2002: “All non-trivial abstractions, to some degree, are leaky.” This one will leak too. For a very short while. There will still be production incidents where somebody has to open the generated code and read it, the same way somebody occasionally still had to read assembly back in 1980s. The skeptics will point at every such incident as proof that nothing changed. But look at what actually happened at every previous transition: the lower skill never disappeared – the population needing it collapsed, from everyone to a specialist niche. Compiler writers still exist; there are just very few of them, and nobody thinks compiler-writing skill is a prerequisite for shipping software. Reading code is heading to the same place. Not to the graveyard – to a museum with a very small maintenance staff.

This ladder was never about layers of syntax. From the plugboard to the prompt, every rung did exactly one thing: it shrank the distance between intent and execution. And at every step there was a residue, the one thing that never got abstracted away – knowing whether what executed is what you actually needed. That skill survived the plugboards, survived assembly, survived every language crusade, and it will survive the agents too, because it is not a layer. It is the reason the ladder exists.