PhronesisThe kernel, granted
Take it literally first, because literally is where it is strongest. A compiler does not translate source straight to machine code. It builds an intermediate representation — a form that is neither what you wrote nor what runs, existing so that optimisation and target selection have something tractable to work on. The middle term is not a metaphor there. It is a named artifact with a data structure.
Widen it and it still holds. A person wants something. They say it. Something turns the saying into a machine state. Code occupies that position, and nothing else does.
Where the phrase slips
“Intermediary to language” smuggles in a claim that code sits outside language, mediating between it and the machine. That is the one part which is simply false.
Programming languages are languages in the exact technical sense: they occupy positions in the Chomsky hierarchy, the same classification built for natural language. Most are context-free or near it. A grammar is a grammar. There is no boundary at which speech stops and code begins — there is a spectrum of formality, and code sits at the strict end of it.
The distinction is not language versus not-language. It is what each one does with ambiguity.
Natural language runs on ambiguity. “Add some plants” is usable precisely because it does not specify how many, which, or where; the listener supplies that, and the underspecification is the efficiency. Code cannot do this. A program that has not decided how many does not run. Every ambiguity in the saying must be resolved by whoever writes the code, and resolved silently, because the machine will not ask.
Naur’s correction, which is sharper than the seed
Peter Naur, 1985: a program is not its source code and cannot be reduced to it. What the programmer builds is a theory — of the problem, and of how execution addresses it. The text is an inscription of that theory, and like all inscriptions it compresses and omits. The intentions, the trade-offs, the reason a boundary sits here rather than there: those live in the people who argued them out.
His conclusion is the uncomfortable one. When everyone holding the theory leaves, the program dies — and it cannot be revived from the text, the documentation, or any artifact, because those never held it. The paper is four pages and has not been improved on.
So the seed is right that code is a middle term, and wrong about which two things it sits between. It is not the intermediary between language and machine — that transfer is lossless, which is the whole point of a compiler. It is the intermediary between intent and machine, and that transfer loses almost everything.
One day of evidence
This note was written on the evening of a day spent turning sentences into a website. The sentences were ordinary: add fruits. Too much blank space. Make the plants HD, keep the bugs pixeled. Each became code, and the code became a thing that could be looked at.
The failures were all of one kind, and it was never a failure to compile.
A band of ground was added to every page. The markup was correct, the file it referenced served a 200, the check that counted it counted it. It rendered as nothing, because a wrapper had collapsed to forty pixels wide. Every intermediary in the chain was faithful and the result was invisible.
Stones scattered through soil were placed by t % 7 === 4, which is periodic by construction, so they came out in three tidy columns at identical depths. The instruction — scatter — was carried perfectly into a rule that does not scatter.
And a gate written to check text contrast passed a region containing no text. It reported success on an empty room. The code did what it said; what it said was not what it was for.
In each case the syntax was clean, the semantics were clean, and the intent did not arrive.
What follows
If code is intermediary to intent rather than to language, one practice follows and it is not a style preference.
The artifact has to be looked at. Reading source verifies the transfer that does not lose anything. It cannot verify the one that does. Every defect above was found by rendering the thing and looking; not one was found by reading the code, and the code was, in every case, available and correct.
And the corollary Naur would insist on: write down the theory, not just the instruction. Not because documentation is virtuous, but because the text omits by nature, and the only defence is to inscribe deliberately what would otherwise stay in a head. A comment recording why the boundary sits here is doing work no amount of clean code does.
Where this could be wrong
Two ways.
The ambiguity distinction may be a matter of degree, not kind. Legal drafting and liturgy are natural language straining toward the precision of code; a program with an undefined behaviour is code straining back. If it is a spectrum all the way down, “code cannot tolerate ambiguity” becomes “code tolerates less,” which is a duller claim.
And Naur may be less true than he was. His argument assumes the theory lives only in people. If a system can be reconstructed from its text by something that reads all of it at once, the death of the program is a claim about human memory rather than about inscription. That is testable now in a way it was not in 1985, and this note does not test it.
References
Naur P, “Programming as Theory Building,” Microprocessing and Microprogramming 15(5):253–261, 1985 — full text, and a second copy. The publisher of record refuses automated requests, so it is given as doi:10.1016/0165-6074(85)90032-8 rather than as a link this site cannot check.
The formal sense in which programming languages are languages: the Chomsky hierarchy. The literal middle term inside a compiler: intermediate representation. On saying as a kind of doing, which is the other half of this and not treated here: speech acts.
The day the evidence came from is in this site’s own history, and the defects are described in Ways of Checking, which catalogues the same failure from the checking side.
Every hyperlink above returns 200.