Think about the software you rely on the most today, right, Like we look at these sleek interfaces on our phones, the seamless notifications, the smooth scrolling, and we view them as finished, polished machines.
Yeah, totally.
But back in nineteen seventy six, one of the absolute pioneers of computer science argued that presenting software this way is well, not just wrong, he said, it makes it completely unfit for human appreciation.
Which is I mean, it is a staggering critique to level at an entire industry. Oh absolutely, And that tension really sits right at the core of our deep dive today into Edgar W. Dykstra's seminal nineteen seventy six book It's called a Discipline of Programming.
Yeah, in Dykster he was looking at this rapidly expanding field back then, right and realizing that by focusing solely on the final executable code, we were basically hiding the actual art exactly.
We were burying the messy, beautiful mathematical design process that you know the software in the first place.
Which is like it's like looking at the final score of a chess game without ever being allowed to see the brilliant strategic moves that were actually played on the board.
Right, you know who won, but you're entirely blind to the intellect that got them there exactly.
And to fix this, Dykstra goes to some pretty wild extremes in this book. I mean, he actually refused to use any of the standard quote unquote higher level programming languages of his era.
Yeah, he hated them. He argued that they're excessive features, like all those bills and whistles we love. They actually belong to the solution set rather than the problem set.
They're just distractions, total distractions.
So he just designs his own minimalist mini language specifically for this text. He forces you to strip away the hardware and focus purely on the logic.
Okay, let's unpack this because the way he visualizes a program without using actual code the cardboard computer.
It's just the cardboard machine. Yeah. He introduces this concept called executional abstraction. It's basically how we map different computations onto each other so our human brains can actually grasp them. And to explain this without any digital hardware, he uses the classic math problem of finding the greatest common divisor the GCD of two numbers.
Right, like say one eleven and two fifty nine exactly.
But he solves it using literal pieces of cardboard. He asked you to imagine two completely different cardboard machines.
Okay, so the first machine, it's deceptively simple. It's just two pieces of cardboard on top of each other. The top piece says GCD one eleven two hundred and fifty nine equals and when you lift that.
Flat, the bottom piece just says thirty seven.
Right, just the answer.
It's the ultimate black box. I mean, it gives you the answer instantly, zero friction, which sounds great, right, it sounds perfect, Yeah, but it possesses a catastrophic flaw for a mathematician. It requires absolute blind faith in the manufacturer.
Yeah, you just have to trust that whoever printed that cardboard didn't like make a TYPEO exactly.
There is zero visibility into the logic, and worse, it only solves that one hyper specific iteration of the problem.
You're completely blind to the logic. You just have to trust the system. And trust is terrible mathematics.
It really is, which is why Dykstra immediately replaces that black box with the second machine. And this one is very different, very this one is a massive piece of cardboard featuring a colossal grid of two hundred and fifty thousand points. You think of an X and Y axis, both stretching from zero all the way to five hundred and cutting right down the middle of this grid is a diagonal answer line where the X coordinate perfectly equals the Y coordinate.
And to operate this massive grid, you play what he calls the pebble game, which I love.
It's so good.
You take a pebble and it represents your two starting numbers, so X is two fifty nine, Y is one eleven, and you place the pebble on that specific coordinate on the grid right. Then you follow one strict geometric rule as long as the pebble is not resting on that diagonal answer.
Line, which it wouldn't be since two fifty nine does an equal one to eleven exactly.
So you look at your axe is you form the smallest equilateral right triangle you can with them, and you move the pebble to the sharp angle of that triangle.
And the geometry here it's just a beautiful physical manifestation of eucliding division.
It's actually kind of wild to picture.
It is because when you drop a perpendicular line to the axes and form that triangle, moving to the sharp angle is literally just subtracting the smaller number from the larger number.
Ah.
So, if you are at two fifty nine to one eleven, the smaller side is one eleven. Moving the pebble physically shifts your ex coordinate down by one eleven, landing you at one forty eight.
You are physically watching subtraction happen in space.
Yes, and you repeat that geometric slide over and over. You keep moving the pebble down and over, down and over until it eventually hits that diagonal line where X and Y are I.
Tentacle, and wherever it lands on that line, that coordinate is your greatest common divisor exactly. Now, I have to be honest, My initial reaction to this was pure pushback. Oh really, yeah, I mean, wait, so, so instead of just giving me a calculator, you've made me play a tedious board game across a quarter of a million potential starting squares just to get the same results. Right.
It feels like way more work.
But then the genius of the trade offf hits you.
Because the tradeoff is the entire point. By establishing that one single compact rule the mathematical invariant, Right, you haven't just solved the problem for two fifty nine and one eleven. You have instantly proven the outcome for all two hundred and fifty thousand possible starting positions on that board.
You trade the immediate, unverified convenience of the first machine for the undeniable, mathematically proven truth of the second machine.
Exactly, a single elegant argument governs every possible game played on that cardboard.
And that is the true essence of an algorithm. It's not about rushing to an output. It's about establishing absolute confidence in the rules that dictate the output.
Right. But if the immense power of an algorithm comes from that absolute mathematical certainty, you face a new problem.
How do you actually communicate those rules?
Exactly? You cannot build a system of flawless, rigid logic using a medium that is fundamentally designed for ambiguity. And this lead Dikstra to deliver a massive warning about what we currently call programming languages.
Yeah, he argues that calling them languages is actually a really dangerous mixed blessing. It's a huge trap because we use natural languages you know, English, Manner and whatever specifically because they are vague. The imprecision of human language is a feature, not a bug.
Right. It allows for poetry and context and nuance reading between the lines.
But formal notation has to be the exact opposite.
It has to be perfectly rigid. If you write the rules of the pebble game using informal words like Euclid originally did thousands of years.
Ago, which was just in Greek, right, right, it.
Remains completely unfit for formal mathematical treatment by an automaton. If we want to create automatic computers, we need unambiguous formal notation.
Calling them programming languages tricks us into reading them like conversations. And you see this constantly today with large language models.
All the time people try to.
Prompt an AI to write highly specific, flawless code using just conversational English, and they get incredibly frustrated when the AI you know, hallucinates or produces unpredictable garbage.
Because the natural language is too vague to hold the strict and variant logic. We are literally using the wrong tool for the job.
And Dykstra saw this trap forming decades ago.
He really did and he pairs this linguistic warning with a sharp critique of early computer history, because in the early days of computing, the hardware was the bottleneck.
It was astronomically expensive and massive, massive.
Highly limited, just incredibly clunky. Consequently, efficiency became the absolute supreme quality criterion for programming.
So whatever made the vacuum tubes or the you know, the magnetic drums spin the fastest was ground the quote unquote best.
Code, which is exactly the problem. Because physical hardware is inherently messy. It's full of bizarre physical quirks. So programmers started writing code that catered to those specific physical anomalies.
They were optimizing for the machine, not for the math.
Right, the code became a truthful reflection of the hardware's weirdness, completely sacrificing the logical beauty of the algorithm.
We were hacking the limitations of the cardboard instead of focusing on the pebble game itself.
That's a great way to put it, and Dykstra argues vehemently that we have to redress this balance. We have to put the pure algorithm back in the center of the universe.
I love how he phrased it in his view, the fact that a piece of metal and silicon can actually execute the algorithm is just a lucky accidental circumstance.
It's such a radical reframing. The execution is secondary, the mathematics are primary.
So what does this all mean? If we accept that the physical machine is just a lucky accident, we have to ask how a program actually organizes its reality in.
The abstract, right, how does it manage what we call a state space?
And the way he describes building this state space is fascinating because it's historically humans named numbers haphazardly. Right, We just invented new words as we needed them.
Like a child counting, just making up sounds.
Exactly, which is impossible to scale. It wasn't until we adopted systematic nomenclature rules that let you drive the next thing, like the decimal system, that mathematics really exploded.
Because systematic nomenclature is about defining boundaries rather than trying to memorize infinite lists. And in computing we build state spaces the exact same way.
Okay, walk us through that.
So Deekster ask us to imagine the mechanical register. Picture a machine with eight wheels, and each wheel holds ten digits zero through nine.
Like a combination lock.
Exactly like a lock, but simply combining those constraints you create a Cartesian product. You instantly define a rigid state space containing exactly one hundred million distinct possible states.
Wow, and once you have that perfectly defined mathematical space, you don't have to wander through it blindly. The source provides this incredibly elegant example of using equations what he calls predicates to define specific conditions within that massive space without ever listing them all out.
Right, because listing one hundred million states would be impossible.
Yeah, so you don't have to list out all three hundred and sixty five days of the year to tell a system what Christmas is.
Well, you just define the state, right, You just.
Define it as month equals December and day equals tots five or day equals twenty.
Six, or defining payday is simply day equals twenty three. It is a compact, flawless way to slice through a massive Cartesian product. It's so clean it is. And this exact mechanism leads to Diykstra's first major surprise while writing this book, The immense power of predicate transformers.
Okay, now this sounds incredibly theoretical, but the application is deeply practical, isn't it.
Oh completely, Because in the early days, programmers would get lost trying to track every single intermediate state a machine passed through during execution.
Like tracking a pinball bouncing around exactly.
It was just total mental overload. Credicut transformers allow a programmer to skip that MetalMan. They let you define a direct relation between your starting state and your final state. Okay, They introduce the formal concept of ROUP, which stands for the weakest precondition. The notation literally looks like rupip and then in parentheses S comma R, where.
S is the system or the program you are running, and are is the result like the post condition you're desperately trying to achieve.
Right, So calculating the weakest precondition is essentially asking what is the absolute broadest, most lenient safety net I need to string up before I hit GO to mathematically guarantee that this system will land exactly on my target.
So you are fundamentally working backwards, entirely backwards. Instead of starting a program and just hoping it gets to the right answer, you start with the undeniably true answer and calculate the exact conditions necessary to make it inevitable.
Yes. And this mathematical rigorousness brings us to property one of his predicate transformers, and I just have to say it possesses quite possibly the most poetic name in the entire history of computer science.
Oh, it really does. The law of the excluded miracle.
Law the excluded miracle.
Which, beyond just sounding beautiful, it perfectly grounds this abstract math in an unbending reality because it states that if your final goal, your desired post condition are is a logical impossibility, which is represented by the state of false right, then there is no starting condition in the universe that can guarantee you will get there.
In formulaic terms, wop of s false equals false.
You cannot ask the machine for magic.
No, if your desired destination contradicts logical reality, no amount of clever programming, no perfect starting conditions, nothing will bend the universe to reach it. The system will fail. The miracle is excluded.
Which is deeply comforting in a way. You know it provides a bedrock of certainty. But all of this flawless invariant logic relies on one massive assumption. What's that It assumes that if you set the starting conditions perfectly, the mechanism itself will carry out the steps exactly as planned. But anyone who has ever used a piece of technology knows that things don't always go according to plan.
The hardware betrays the math.
Exactly the hardware betrays the math.
And this realization leads directly to Dykstra's second and perhaps most profound surprise in the book, Because up to this point in computer science history, deterministic machines were the unquestioned holy.
Grail, deterministic meaning perfectly predictable.
Right, The entire discipline was built on the assumption that identical initial states must one hundred percent of the time yield identical outcomes, utter unbreakable predictability.
But the physical world doesn't really like perfect predictability, does it not at all?
And Dykester shares this genuinely harrowing story from nineteen fifty eight.
Yeah, this part blew my mind.
He was working with a new machine that featured an io interrupt, basically an external hardware signal that could asynchronously pause the current process. Right, And because this interrupt was tied to physical timing rather than logical steps. It caused irreproducible nondeterministic behavior.
Meaning the machine would execute differently even when provided the exact same initial state exactly.
A hardware glitch or you know, a microsecond timing delay would evoke an erratic error that you couldn't reliably reproduce to study. It was a ghost in the machine, a total ghost, and Dyscher was paralyzed by this. He literally referred to the machine as an intractable beast.
Intractable beast.
He was so terrified by the prospect of having to build reliable, flawless software on top of a fundamentally unpredictable foundation that he delayed a major software design decision for three entire months.
Wait, three whole months, three months over one unpredictable interrupt. That is just It really illustrates how foundational perfect determinism was to their entire worldview.
Back then, it was everything to them.
Unpredictability wasn't just a bug, It was the colle apse of mathematical certainty itself.
Right. But eventually he has this massive psychological and mathematical breakthrough. He realizes that his terror wasn't because the machine was inherently broken. His terror stemmed entirely from a lack of methodology.
He didn't have the mental models to process the unpredictability.
Exactly, and when he finally develops those models, he flips the entire paradigm of computer science on its head. He comes to regard nondeterminacy as the normal default situation of complex systems.
He decides that perfect determinism, the thing they had worshiped for decades, is actually just a special, highly restricted, and in his own words, not even very interesting case of nondeterminacy.
It completely shatters the illusion. It's like accepting that friction is the reality of the physical world and a frictionless vacuum is just a highly specialized laboratory condition.
That's a perfect analogy.
And once Diyster accepts this, he begins building constructs that actively embrace a level of nondeterminacy rather than fighting it. He stops overspecifying how the machine.
Should behave Here's where it gets really interesting. The source gives a brilliant example of this with his concept of concurrent assignment. Yes, the concurrent assignment, because in traditional highly deterministic programming, if you want to swap the values of variable x and variable Y.
You can't just swap them, No, you can't.
You have to create a temporary third variable. You move x to tempt, then you move Y to X, then you move temp to hy. It is a rigid, hyper sequential step by step march.
It forces a strict chronological sequence where none is logically necessary. You're basically over constraining the machine.
Right, and Deekstra's concurrent assignment elegantly sidesteps this whole dance by simply writing X comma Y becomes y comma x right.
Just swap them simultaneously.
You define the post condition, the values are swapped, and you leave the exact mechanical sequencing slightly ambiguous. You allow for nondeterminacy in the how safely bounded by the mathematical invariant of the what.
You stop micromanaging the intractable beast and you start guiding it with flawless logic.
Which perfectly synthesizes the massive journey Diekstra takes us on in this book. I mean he wanted to pull us away from being glorified mechanics just endlessly catering to the physical anomalies and sequential limitations of whatever metal box happen to be sitting on our desks.
We start with that massive cardboard grid, realizing that true algorithmic beauty isn't about getting a fast answer, It's about establishing a mathematical invariant that proves the truth across a quarter of a million possibilities right.
And we learn to abandon the dangerous vagueness of natural languages, recognizing that human ambiguity has absolutely no place in the rigid architecture of an automaton.
Exactly, we arm ourselves with predica transformers. We learned to work backwards from our desired reality to find that weakest precondition, always always respecting the law of the excluded miracle.
We cannot ask for magic.
We cannot ask for magic.
And finally, we watch one of the greatest minds in the field suffer a three month panic attack over an unpredictable interrupt, only to emerge with the absolute revelation that rigid determinism is a myth.
Nondeterminacy is the true nature of complex systems, and true programming elegance is learning to mathematically guide that unpredictability rather than fearing it.
He elevates software from a mechanical chore to a goal directed activity of profound mathematical beauty. He asked us to look past machine and marvel at the logic itself.
It's a beautiful way to look at the world, which leaves.
You, the listener, with a really fascinating lens through which to view the technology surrounding you today. Because we live in an era that is increasingly dominated by massive AI models and neural networks that are fundamentally, by their very architecture, non deterministic.
They absolutely are.
They hallucinate, They surprise us. They produce irreproducible outputs. If a pioneer like Diikstra realized way back in nineteen seventy six that unpredictable, non deterministic systems are the normal state of reality rather than a glitch to be feared.
How should that change your expectations exactly.
When an algorithm surfaces a bizarre result, or an AI gives you an answer you didn't anticipate. Perhaps the system isn't broken. Perhaps we are simply still stubbornly demanding the flawless cardboard determinism of the past from the wonderfully and tractable beasts running our future.