Out now · Paperback & Kindle
The Next
Programming
Language
Why It Won't Be Written by Humans
Programming has lived through three language eras in roughly eighty years, and twice authorship moved upward. Each time, the level below did not disappear. It stopped being written by people and started being emitted by machines.
Today AI writes Python — not because anyone judged it the right target for a machine author, but because it is what the training distribution contained.
The author has just changed again. This book designs what should come out instead — and builds it.
- chapters
- 27chapters
- runnable labs
- 8runnable labs
- pages
- 178pages
- working language
- 1working language
The load-bearing claim
“The property that matters in a machine-authored representation is not ease of generation — that half already works — but ease of deterministic correction and verification after generation.”
Nearly every decision in the second half of the book falls out of taking that one requirement seriously.
Part I — Every language has an author
Three eras. Two transitions. The same reason each time.
Each transition was resisted with the same sentence — the generated code isn’t as good as hand-written. Both times the objection was true when it was made, stayed true for years, and was never quite refuted. The economics moved underneath it instead.
Era 1
Machine code
for the machine
Almost nobody hand-writes it any more
Now emitted
Era 2
Assembly
for engineers
Most of it is no longer written by hand
Now emitted
Era 3
High-level source
for programmers
Written by us — and increasingly not
Still written
Era 4
The next language
for a machine author
Does not exist yet. Part V builds one
Not yet written
Chapter 1
The same function, four times
Only the first one is bytes. The rest are descriptions of bytes.
Compile that C for x86-64 with optimisation on and you get exactly b8 2a 00 00 00 c3 back. Compile it on Apple Silicon and you get eight entirely different bytes. Same C. Same meaning. Nothing in the source said which.
So isn’t English the fourth language? That objection arrives on page one, and the book takes it seriously rather than leaving it until Part IV.
Machine code
written by nobody
b8 2a 00 00 00 c3Assembly
written by almost nobody
mov eax, 42
retHigh-level source
written by us — for now
int answer(void) { return 42; }English
written by us
Write a function that returns 42.Same meaning, four times. As you move down the list you stop writing the bytes and start describing them — and you hand somebody else the decision about what they actually turn out to be. The English at the bottom hands over the most of all.
Part II — With measurements
What it costs to make a machine write like a human
Part II demonstrates rather than surveys. Each cost is shown on a worked example small enough to check by hand and reproduce from the labs — with Python and Clang, on your own machine.
Lab 01–04
Invalid LLVM IR is accepted
Machine bytes, source to native, LLVM IR, and SSA rules that are not actually checked.
Lab 06
6 of 9 faults silent
Nine faults injected across languages. Six of them are silent in every language tested.
Lab 07
40% → 100% repair
The same fault, two error messages. A conventional message repaired it 40% of the time; a diagnostic naming the violated obligation and enumerating the legal repairs, 100%. Format alone did nothing (p = 0.36).
Lab 08
R² = 0.9996
Repair cost scales linearly with program size when the unit of change is the whole program.
One experiment reported in the book found that models repaired distributed faults forty per cent of the time when given a conventional error message, and one hundred per cent of the time when given a diagnostic that named the violated obligation and enumerated the legal repairs.
Changing the message’s format alone did nothing (p = 0.36). The content is what moved the number.
See all eight labsPart V — The language
AIR is not a sketch. It parses, verifies, compiles and runs.
Nine chapters build it from a first program to native code. It is deliberately small — a language you can read in an afternoon is a language you can argue with — and the book is precise about which fragment of computation it covers.
Fragments with stable identity
A program is addressable. A fault names a fragment, and repair touches that fragment rather than regenerating the file.
Diagnostics as a protocol
A structured record: a stable code, the fragment at fault, the obligation not met, whether it is false or merely unproven, the finite set of legal repairs, and how much may be touched in response.
Declared effects and capabilities
What a fragment is permitted to do with the world is written down, and checked, rather than discovered when it runs.
Contracts and explicit freedoms
What must hold is stated. So is what the compiler is free to choose — which is the part conventional languages leave implicit and then argue about.
Chapter 27
It closes by listing what would prove it wrong
Eight observations, each with the experiment that would produce it — including two measurements the argument openly owes and has not taken. A design book that cannot say what would refute it is not making a claim; it is expressing a preference.
What it does not claim
- That programmers disappear — people still review, debug and own the code.
- That models will get better and that settles it.
- That a model is a compiler. It is a compiler-like producer, which is a different and more awkward thing.
- That AIR is finished, or covers all of computation. Appendix A.12 states the fragment.
What it does claim
- The primary producer of code has changed, as it did twice before.
- The languages being produced were shaped, feature by feature, around a human author.
- The binding cost is correction after generation, not generation.
- A representation designed for that is buildable — and here it is, running.
The author
Ajay Malik
Three decades building the infrastructure everyone agreed was permanent. Head of Architecture and Engineering for Google’s worldwide corporate network; executive leadership at Hewlett-Packard, Cisco, Qualcomm and Motorola. Around 110 patents, several startups founded and exited, and five books.
He has watched authorship move before, twice, in networking and in systems software. This is an argument about the third time.
More about AjayThe author has changed. The language hasn’t — yet.
For software engineers, architects, compiler engineers and technical leaders responsible for systems increasingly written by machines.
ISBN 979-8-9877684-1-9 · 6″ × 9″ paperback · Kindle