The entire AI data centers’ compute resources are all trying to fight over getting more FLOPs (Floating Point Operations). Creating a big model is trillions times trillions of FLOPs, run for multiple weeks. But people didn’t trust the results of FLOPs not so long ago. There was a lot of doubt that floating-point arithmetic could happen correctly. There’s some rounding that happens, and the worry was that all the rounding would lead to a really big error and the answers would be wrong.

It was Wilkinson, who got the Turing Award in 1970, who changed that. He helped introduce a new way to measure the answer and check if we can trust it. Forward errors are hard to compute in general because you need the right answer and then do the subtraction, but backward errors are much easier to compute. It’s how much you have to nudge the inputs to make your answer exactly right. Instead of thinking if the result answered the question perfectly, think what question did the result answer, and for very well-designed algorithms the answer is very, very little, 10 to the minus 16 or something very small.

This became the gold standard on how to measure how good algorithms are. Backward errors are always in reason; they stay about the size of the rounding. But errors can still get big, and that’s because of finicky inputs, not just because of algorithms. A finicky input blows up the error no matter what algorithm you use or what machine it runs on. How finicky the input is is called the condition number. So it comes together like this:

forward error ≈ condition number × backward error

TLDR: he helped build confidence in algorithms that do floating-point arithmetic, which is the foundation of everything in the AI world today.

Code, a runnable demo, and the full writeup: Github project

Week 04 of my learning series on Turing Award winners: Marvin Minsky.

Marvin Minsky, along with John McCarthy, was hugely pivotal in starting AI as a field. They organized the Dartmouth conference in 1956, got the best minds in the room, named the discipline of AI, and then went off and built the two institutions that shaped everything after: Minsky at MIT, McCarthy at Stanford.

The MIT AI Lab is still running today as CSAIL.

My Take

The first highlight is moving from flat lists of rules to structured knowledge. Before his frames paper, AI systems stored knowledge as giant if-then rule lists, which doesn’t scale well. Minsky’s intuition was that this is very different than how humans think. When you see a chair, your brain doesn’t rederive what a chair is from scratch every time. It has a mental template made up of four legs, a back, a seat, some material, and you fill in the details. He called that idea of structure “frames”: structured objects with named slots and defaults. This is how most programming languages work today in terms of classes and objects.

The second, and the more important one, is his book on perceptrons and their limitations. Rosenblatt’s single-layer network was the hot AI thing in 1958, and there was a lot of optimism that you could scale this infinitely and solve intelligence. Minsky was the party pooper and proved mathematically that regardless of data size or compute, a single layer isn’t enough for a computer to understand even a basic operation like XOR. This did play a big role in the first AI winter: funding dried up, research stalled, the whole neural network agenda lost momentum for nearly a decade. Minsky, to his credit, also explicitly said that multi-layer networks wouldn’t have this problem and pushed researchers towards training them. Backpropagation for multi-layer networks arrived in 1986, which was a big unlock, followed by deep learning. The AI era we know today: H100 clusters, hyperscalers, Mag-7, all training the next frontier models. All of it traces back to Minsky pushing the world towards multi-layer networks.

What He Actually Did

Marvin Minsky won the Turing Award in 1969 “for his central role in creating the science of artificial intelligence.”

Two contributions stand out:

1. Frames — Structured Knowledge (1974)

Before Minsky’s frames paper, AI systems stored knowledge as giant if-then rule lists. If you wanted a computer to understand what a chair is, you’d write hundreds of rules: “if object has four legs AND has a back AND has a seat, then object is chair.”

It doesn’t scale. The rules explode combinatorially.

Minsky’s insight: humans don’t work that way. When you see a chair, your brain doesn’t rederive what a chair is from scratch. It has a mental template. Four legs. A back. A seat. Some material. Default values. You fill in the details.

He called this structure “frames”: objects with named slots and defaults.

Frame: CHAIR
  slots:
    legs: 4 (default)
    back: yes (default)
    seat: yes (required)
    material: wood (default)

This became the foundation of object-oriented programming. Classes with properties. Inheritance. Defaults. It’s how Python, Java, JavaScript work today.

2. Perceptrons — The Limitation That Pushed AI Forward (1969)

In 1958, Frank Rosenblatt built a learning machine called the perceptron. You showed it examples — this input means yes, that input means no — and it adjusted its internal numbers (weights) until it got them right.

It had a mathematical guarantee: if a pattern can be separated by a straight line, the perceptron will find the weights.

The problem was the fine print: “if a pattern can be separated by a straight line.”

The XOR Problem

XOR is a simple logic function:

0 XOR 0 = 0
0 XOR 1 = 1
1 XOR 0 = 1
1 XOR 1 = 0

Plot these four points on a grid. The 1s sit at diagonal corners (0,1) and (1,0). The 0s sit at the other diagonal corners (0,0) and (1,1).

No straight line can separate them. Try it. Every line you draw leaves at least one point on the wrong side.

A perceptron computes the sign of a linear function: w1·x1 + w2·x2 + b. The decision boundary is a straight line. Since XOR isn’t linearly separable, no perceptron can learn it — ever, no matter how many training rounds you run.

Minsky’s Proof

Minsky and Papert spent years in the 1960s mapping out exactly which patterns fail. Their 1969 book proved it rigorously.

For XOR, the constraints are:

(0,1) → 1:   w2 + b ≥ 0       →   w2 ≥ -b
(1,0) → 1:   w1 + b ≥ 0       →   w1 ≥ -b
(0,0) → 0:   b < 0             →   b < 0
(1,1) → 0:   w1 + w2 + b < 0

From b < 0, say b = -1. Then w1 ≥ 1 and w2 ≥ 1.
But then w1 + w2 + b ≥ 1 + 1 - 1 = 1 > 0, so (1,1) fires — contradicting the fourth constraint.

No values of w1, w2, b satisfy all four constraints simultaneously. The system is inconsistent.

This is not a computational problem. It is a proof. Single-layer networks cannot solve XOR, period.

The First AI Winter

The book effectively ended the first era of neural network optimism. Funding dried up. Research stalled. The whole neural network agenda lost momentum for nearly a decade. People remember this as “Minsky killed neural networks.” But that’s not the full story.

What Minsky Actually Said

The book acknowledged explicitly that adding hidden layers broke the representational limits. Multi-layer networks could solve XOR. The problem was that no training algorithm existed for multi-layer networks in 1969.

The perceptron learning rule applies only to the output layer. Updating hidden layer weights requires knowing how each hidden neuron contributes to the output error, which requires propagating the error signal backward through the network.

That algorithm — backpropagation — arrived in 1986.

The Two-Layer Solution

With two layers, XOR is solvable. The hidden layer learns two intermediate features (OR and NAND) and reshapes the problem into one the output layer can handle with a single line.

Here’s the geometry:

Hidden neuron h1 (computes OR): 
    (0,0) → h1=0
    (0,1) → h1=1
    (1,0) → h1=1
    (1,1) → h1=1
Hidden neuron h2 (computes NAND):
    (0,0) → h2=1
    (0,1) → h2=1
    (1,0) → h2=1
    (1,1) → h2=0
New feature space (h1, h2):
    (0,0) → (0, 1)
    (0,1) → (1, 1)
    (1,0) → (1, 1)
    (1,1) → (1, 0)

In this new space, XOR is linearly separable. The output neuron computes AND of h1 and h2. Done.

The hidden layer didn’t learn XOR directly. It learned two simpler features and created a transformed space where the XOR points ARE linearly separable.

Minsky’s proof said: you cannot do this with one layer. He was right. Two layers is the minimum.

Where This Led

Backpropagation (1986): Rumelhart, Hinton, and Williams popularized the algorithm for training multi-layer networks. Gradient descent through a network of sigmoid units. Automatic differentiation. The training method Minsky said was missing.

Deep Learning (2006+): Stacking many hidden layers. GPUs, large datasets, architectural improvements (ReLU, dropout, batch normalization). GPT, DALL-E, AlphaFold, every major neural network today.

Universal Approximation Theorem (1989): Proved that any continuous function can be approximated arbitrarily closely by a single hidden layer of sufficient width. The Minsky-Papert limitation applies only to single-layer networks.

All of it traces back to Minsky proving what single-layer networks can’t do. The proof defined the problem space. Backpropagation solved it.

The Code

I built a perceptron simulator that shows the XOR failure:

Perceptron on AND (converged in 6 epochs):
 0 0 → 0  (expected 0)  ok
 1 1 → 1  (expected 1)  ok
LEARNED

Perceptron on XOR (1000 epochs, never converges):
  0 0 → 1  (expected 0)  WRONG
  0 1 → 1  (expected 1)  ok
  1 0 → 0  (expected 1)  WRONG
  1 1 → 0  (expected 0)  ok
FAILED  (accuracy 50% — best any single-layer net can do)

Two-layer net on XOR (10000 epochs, backprop):
  0 0 → 0  (expected 0)  ok
  0 1 → 1  (expected 1)  ok
  1 0 → 1  (expected 1)  ok
  1 1 → 0  (expected 0)  ok
LEARNED 

With --verbose, you see the weights update, the hidden layer learn OR and NAND, and the output layer combine them.

Full code and worked example on GitHub: github.com/nirmal91/turing-award-series

Why This Matters

Minsky didn’t kill neural networks. He defined their limits precisely, mathematically, with a proof.

That precision is what made progress possible.

Before the Perceptrons book, researchers made expansive claims about what single-layer networks could eventually learn. There was no formal framework for asking: what can’t a perceptron learn, and why?

After the book, the question was answered. Single-layer networks have a geometric limitation. Add a hidden layer. Learn intermediate features. Transform the space.

When backpropagation arrived in 1986, it gave researchers exactly what the Minsky-Papert proof said was missing. Every modern neural network is, in a sense, the answer to their 1969 theorem.

The H100 clusters training frontier models today. The hyperscalers. The Mag-7. All running multi-layer networks that solve problems Minsky proved single-layer networks cannot.

He was the party pooper who proved the old approach wouldn’t scale. And in doing so, he pointed to exactly what would.

This is Week 04 of the Turing Award Series. New entry every week. All code is on GitHub.

← Previous: Week 03 — When Bits Flip and Everything Breaks (Richard Hamming)

Week 03 of my learning series on Turing Award winners: Richard Hamming.

Richard Hamming, a mathematician, was trying to do what all of us do today. Submit a bunch of jobs Friday evening, expect the machine to keep running all weekend, and have stuff ready Monday morning.

It wasn’t as smooth for him. He’d come back with nothing done, because random bits were flipping mid-run, corrupting the computation and stopping it cold.

My Take

He decided the data could carry enough extra information to fix itself. A few extra bits added to whatever you’re transmitting is all it takes, and if a bit flips in transit, those bits tell you exactly which one flipped so you can fix it without retransmitting or restarting. This is now the foundation of everything we do. Think about RAM, SSDs, hard disks, QR codes, even deep space telemetry. Most error-correcting codes today trace back to this one 1950 paper.

Bit flipping happens way more than you’d expect. RAM is the worst case. Google published a study showing a typical server sees one to two bit flips a day in memory, and a data center has hundreds of thousands of machines with bits flipping constantly. Without error correction, servers silently compute the wrong answers. It would feel like the servers are hallucinating and giving you wrong answers.

The Mag-7, the hyperscalers, the H100 clusters training the next frontier model, they all run on hardware that self-corrects at the bit level, all because of Hamming’s work in 1950.

What He Actually Did

Richard Hamming won the Turing Award in 1968 “for his work on numerical methods, automatic coding systems, and error-detecting and error-correcting codes.”

The error-correcting code is what changed everything.

The Problem

In the 1940s, computers at Bell Labs ran on punched cards and electromechanical relays. They were unreliable. Bits would flip. A calculation that ran overnight would finish with a wrong answer, and you’d have no idea where the error crept in.

Hamming worked weekdays. The machine ran his jobs on nights and weekends. Every error cost him a full week of waiting.

He spent his weekends furious about this.

The Insight

Before Hamming, error detection existed. A single parity bit appended to a byte can tell you that some bit flipped, but not which one. To correct an error you need to know its location.

Hamming’s idea: add a few extra bits whose values are determined by the data bits. These “parity bits” are placed at specific positions so that any single flipped bit disturbs a unique combination of them.

The receiver checks all the parity bits and computes a number called the syndrome.

If the syndrome is zero, no error.

If it’s nonzero, the syndrome is literally the position of the bad bit. Flip it back. Done.

How It Works — Hamming(7,4)

4 data bits become 7 bits total. Three parity bits buy you full single-error correction.

Here’s the actual process:

Step 1: You have data to send: 1011

Step 2: Positions that are powers of 2 get parity bits. Everything else gets data.

position:  1    2    3    4    5    6    7
type:     p1   p2   d1   p4   d2   d3   d4
bit:       ?    ?    1    ?    0    1    1

Step 3: Each parity bit covers specific positions based on binary representation.

• p1 (pos 1): covers positions 1, 3, 5, 7

• p2 (pos 2): covers positions 2, 3, 6, 7

• p4 (pos 4): covers positions 4, 5, 6, 7

Each parity bit is set so its group XORs to zero:

p1: 1 XOR 0 XOR 1 = 0  →  p1 = 0
p2: 1 XOR 1 XOR 1 = 1  →  p2 = 1
p4: 0 XOR 1 XOR 1 = 0  →  p4 = 0

Final codeword: 0110011

Step 4: Transmit it. A bit flips. Position 5 changes from 0 to 1.

sent:      0  1  1  0  0  1  1
received:  0  1  1  0  1  1  1
                       ↑
                   bit flipped

Step 5: Receiver recomputes all three groups:

p1 checks 1,3,5,7:   0 XOR 1 XOR 1 XOR 1 = 1  ✗  broken
p2 checks 2,3,6,7:   1 XOR 1 XOR 1 XOR 1 = 0  ✓  fine
p4 checks 4,5,6,7:   0 XOR 1 XOR 1 XOR 1 = 1  ✗  broken

Stack the results: p4=1, p2=0, p1=1 → binary 101 → 5

The syndrome points directly to position 5. Flip it back. Extract data: 1011 ✓

No retransmit. No restart. The data fixed itself.

Where You See This Today

ECC Memory: Every server in every data center. RAM modules have extra chips that store Hamming parity bits. When a cosmic ray flips a bit, the memory controller computes the syndrome and corrects it silently.

QR Codes: Reed-Solomon error correction, a descendant of Hamming codes. You can scratch off 30% of a QR code and it still scans.

Hard Disks and SSDs: Every sector has error-correcting codes. Bits rot. Controllers fix them.

Deep Space: Voyager uses Reed-Solomon codes over GF(2⁸). It’s 15 billion miles away and still sending data through a 20-watt transmitter. Error correction makes that possible.

5G and Wi-Fi 6: LDPC codes (low-density parity-check), which trace their lineage to Hamming’s insight.

All of them use the same core idea: extra bits, placed carefully, that locate errors algebraically.

The Code

I built a full Hamming(7,4) codec:

• Encode any ASCII string into Hamming codewords

• Inject single-bit errors at random positions

• Auto-correct every injected error, no retransmit needed

> Hello world
  encoded: 11 bytes → 154 transmitted bits
  injected error: char 2 (hi nibble) bit 3
  injected error: char 5 (lo nibble) bit 6
  injected error: char 9 (hi nibble) bit 1
  recovered: "Hello world"  (3 error(s) auto-corrected)
  result: perfect match

With --verbose, each decode step shows the syndrome computation:

char 2:
    syndrome bits: s1=1 s2=1 s4=0  →  3
    error at position 3, flipping
    decoded: hi=[1,1,0,0] lo=[0,0,0,0]  byte=0x6C

The syndrome is a binary number that names the bad position directly. That’s the invention.

Full code and worked example on GitHub: github.com/nirmal91/turing-award-series

Why This Matters

Before Hamming, a flipped bit meant failure. Retransmit. Restart. Hope it doesn’t happen again.

After Hamming, a flipped bit is a number. Find it. Fix it. Move on.

That shift — from detection to correction, from “something’s wrong” to “position 5 is wrong” — is what made reliable computing possible.

RAM flips bits constantly. Cosmic rays. Alpha particles from chip packaging. Just random quantum noise. Without error correction, servers would hallucinate. Databases would corrupt. Training runs would diverge.

Hamming didn’t just build a better parity check. He proved that data could carry the instructions for its own repair. That the mathematics of geometry — Hamming distance, spheres on hypercubes — could locate errors in real hardware.

Every H100 in every cluster training the next frontier model has ECC memory correcting bit flips in real time. Every QR code you scan has Reed-Solomon correction letting you read it through scratches and smudges.

Hamming got mad at a machine that wasted his weekends. He wrote the mathematics to make it stop. And we’ve been building on that mathematics for 75 years.

This is Week 03 of the Turing Award Series. New entry every week. All code is on GitHub.

← Previous: Week 02 — When Changing a Computer Meant Rewiring It (Maurice Wilkes)

Week 02 of my learning series on Turing Award winners: Maurice Wilkes.

Before Wilkes, if you wanted to change how a computer worked, you changed the hardware. He made it a software problem instead.

My Take

Every small change required rewiring. New chips, new gates, because instructions were hardcoded into the silicon. If you wanted to add one, or fix one, you weren’t updating code. You were rebuilding the machine.

Wilkes changed that in 1951 with microprogramming. Instead of hardcoding operations into hardware, he introduced a recipe book stored in ROM (read only memory), called a control store. If you wanted to change how the underlying hardware behaves, don’t touch transistors and just change the recipe. That was a massive shift in reusability and portability.

Almost all progress over the last 70 years has been about adding more of these abstractions, each one building on the last. BIOS, operating systems, applications. All follow the same pattern. I have always dreaded on-prem compared to cloud because it seems painful to slowly push updates, bulk things, etc. Having to actually change hardware seems like 100x more complex, which was the norm before Wilkes. The thing we take for granted, that you can change behavior without touching the machine, started here.

What He Actually Did

Maurice Wilkes won the Turing Award in 1967. The citation focused on EDSAC, the first stored-program computer he built in 1949. But the idea that changed everything came two years later.

Microprogramming (1951)

Before this, every instruction a computer understood was wired directly into its hardware. The circuits for “add two numbers” were physical relays and vacuum tubes, soldered in a fixed arrangement.

If you wanted to add a new instruction, you had to redesign the circuitry.

IBM hit this wall. They’d committed the chip design before realizing they’d left out useful instructions. Too late to fix without building a new machine.

Wilkes’s idea: instead of wiring instruction logic into hardware, write it down in a small read-only memory called a control store.

Each machine instruction’s behavior is encoded as a sequence of microinstructions in ROM. Nothing is hardwired. To add a new instruction, you add new entries to that memory. No hardware change required.

Here’s what that looked like:

Before Wilkes, to execute ADD, the control unit would:

1. Route PC to memory — fixed gate path

2. Latch memory output into IR — fixed path

3. Increment PC — hardwired circuit

4. Decode opcode — fixed logic activating the ADD signal

5. Route memory to ALU — fixed wire

6. Route accumulator to ALU — fixed wire

7. Assert ALU = ADD — activates adder

8. Write result back — fixed feedback path

Every step permanently etched into hardware.

After Wilkes, the same ADD is just two microinstructions in ROM:

μ16: MDR ← MEM[MAR]       ; load the value
μ17: A   ← A + MDR        ; add it to accumulator 

The hardware is generic. The specific behavior lives in ROM entries. To add ADD_TWICE that adds memory to A twice, write two new ROM entries. No hardware change.

Why This Mattered:

IBM could build a cheap slow machine and an expensive fast machine that ran the same programs. Like a Toyota and a Ferrari that both respond to the same steering wheel. Each had different hardware underneath, but the same instructions on top, each implemented in its own microcode.

That was the IBM System/360 in 1964, and it changed the industry. Eight models spanning a 50:1 performance range, all running the same software. Only possible because of microprogramming.

Modern Intel and AMD chips still work this way. When Intel patched the Spectre vulnerability in 2018, they didn’t ship new hardware. They pushed a microcode update. Changed the behavior by rewriting control store entries, not replacing chips.

The Code

I built a microprogrammed CPU simulator that mirrors Wilkes’s 1951 architecture. It has:

• An assembler that turns assembly into machine code

• A control store (68-word ROM) holding microprograms

• 16 machine instructions, each implemented as microcode

Run it in a REPL:

> LOADI 10
> STORE 200
> LOADI 25
> ADD 200
> HALT

>
  5 instructions  (26 μcycles)
  A=35  B=0  PC=5

With --verbose, you see the microinstruction trace. The ADD instruction expands into six microinstructions, each controlling the data path for one clock cycle:

[  3] PC=3  ADD 200
  μ00: MAR←PC          [MAR: 200 → 3]

  μ01: MDR←MEM[MAR]    [MDR←12488]

  μ02: IR←MDR          [IR: 24576 → 12488]

  μ03: PC←PC+1  →DISPATCH  [PC: 3 → 4]

  μ16: MDR←MEM[MAR]    [MDR←10]

  μ17: A←A+MDR  →FETCH [A: 25 → 35]

That’s the Wilkes layer. One machine instruction becomes many microinstructions.

Full code and explanation on GitHub: github.com/nirmal91/turing-award-series

Why This Matters

Every abstraction we have today traces back to this moment.

Wilkes proved you could separate what a computer does from how it does it. The behavior lives in data, not silicon. Change the data, change the behavior.

BIOS does this. Operating systems do this. Virtual machines do this. Cloud infrastructure does this. Docker containers, Kubernetes, serverless — all variations on the same theme: define behavior as configuration, not hardware.

We take it for granted now. Push an update, behavior changes. No rewiring. No new chips.

But someone had to prove you could do that. Someone had to be first.

That person was Maurice Wilkes, in 1951, with a control store and a microprogram.

The abstraction layers have been stacking ever since.

This is Week 02 of the Turing Award Series. New entry every week. All code is on GitHub.

Previous: Week 01 — The First Compiler (Alan Jay Perlis)

I miss learning for the sake of learning. Going into rabbit holes. Reading research papers has always been aspirational for me but hard to be consistent with.

What’s different now is that the barrier to actually grokking hard concepts is so much lower. You can take a dense 1960s systems paper, work through it with an LLM, and come out the other side genuinely understanding it. You can customize the learning based on your skills, your experience, your knowledge.

So I’m starting a series on Turing Award winners and other CS papers I find interesting.

How This Works

Most of it will be AI generated: the code, the write-ups, the structure. But every entry has one section written by me. Writing is how I think. It’s what validates my understanding.

This is that section.

My Take

We’ve gone through tons of advancements in computer languages over the years, but at the heart of everything, computers have always understood it the exact same way. We have built abstractions on top, like Scala, Javascript, Python and, most recently, English as a new programming language, but deep, deep down inside, computers have always looked at zeros and ones, or things to do operations to manipulate an actual bit on a disk or something. That has never changed.

What makes Alan Jay Perlis’s work stand out is that he was the first to say humans don’t have to do the hard work of translating things into how computers understand them. You should be able to write a simple mathematical equation or formula, and the compiler will do the translation. Not everyone has to understand and write machine code. He was the first to invent something humans could write in instead of having to write machine code.

The other thing he did really well was try to get all of the best computer science minds in the world to come to a common way of thinking about languages and compilers. That’s what allowed developers to be so easily able to move around, and the concepts remain similar across all programming languages. It’s because of what Alan Jay Perlis did, and now, because all the languages are so similar, LLMs have been able to understand those languages really, really well. That’s why we can program in English today.

What He Actually Did

Alan Jay Perlis won the first Turing Award in 1966 “for his influence in the area of advanced programming techniques and compiler construction.”

Two things stand out:

1. IT — The Internal Translator (1955–56)

Before Perlis, programmers wrote machine code by hand. Every instruction was a string of numbers. If you wanted to compute x = (a + b) * c, you’d write something like:

65  0100  0011

15 0101 0012

19 0102 0013

24 0103 0014

Each line is one instruction. The numbers mean: clear the accumulator, load a value, add another value, multiply, store the result. The last four digits of each instruction told the computer where on the spinning drum to find the next instruction. If you got it wrong, the machine waited a full rotation. Programming wasn’t just logic. It was a timing puzzle.

Perlis built a translator. You typed normal math. The compiler figured out the machine code. That was IT. It was the first compiler that actually worked.

People didn’t think you could do this automatically. They thought machine code needed human cleverness. Perlis proved them wrong.

2. ALGOL 60 — The Language That Taught Every Language

In 1958 Perlis chaired a meeting in Zurich with mathematicians and computer scientists from America and Europe. The goal: agree on one language that would work everywhere.

That language became ALGOL 60.

ALGOL 60 introduced:

• Block structure (variables that stay inside their { })

• Recursion (functions calling themselves)

• Formal syntax (the first language defined by a grammar, not prose)

• Type declarations (variables had declared types)

Every language since borrowed these ideas. Python, Java, C, Go, Rust — they all descend from ALGOL 60.

This is why modern programming languages look so similar to each other. This is why LLMs trained on code can understand them so well. This is why we can now write code in English and have it work.

The foundation was laid in 1960.

The Code

I built a mini compiler that mirrors what IT did: take text, turn it into tokens, build an abstract syntax tree, compile to bytecode, execute.

It’s 200 lines of Python. No external dependencies. You can run it in a REPL and see it work:

> x = 3

> y = x * (2 + 4)

> y

18

Or you can run python compiler.py --verbose and watch it turn your expression into stack bytecode, instruction by instruction.

The full code and explanation are on GitHub: github.com/nirmal91/turing-award-series

Why This Matters

We take compilers for granted now. Type some Python, hit run, it works. But someone had to be first. Someone had to prove you could do this automatically. That programming didn’t have to be hand-translating human thought into machine numbers.

That person was Alan Jay Perlis.

And because he got the best minds to agree on a common structure for languages, every language since has been learnable if you know one. The abstractions stack. The concepts transfer.

That’s why, 70 years later, we can hand an LLM a piece of Python and a piece of Go and it understands both. The grammar is shared. The ideas trace back to the same meeting in Zurich.

Perlis built the foundation we still code on.

This is Week 01 of the Turing Award Series. New entry every week. All code is on GitHub.