Notation as a Tool of Thought in the Age of AI

APLflow · Amsterdam · July 2026 · draft for comment

A language before a machine

In 1962 Ken Iverson published a book called A Programming Language. The title was half wishful: what the book described could not be programmed on anything. It was a notation, a compact algebra for describing operations on whole arrays of data, meant for blackboards and papers and thinking. For four years people used it the way mathematicians use any good notation, as a tool of thought. Then IBM built an interpreter, APL\360, and the notation became a programming language after the fact.

APL went on to a strange career: beloved in finance and insurance, influential on the spreadsheet and on every array library since, and ultimately pushed to the margins. The standard explanation blames the funny symbols. I think the deeper reason is more mundane: the gap between notation and running software stayed expensive. Every idea expressed in notation had to be translated, by a scarce human expert, into whatever the surrounding system was built from. The industry standardized on languages that were cheap to translate because they were the implementation: C, then Java, then Python. Notation lost to typing.

Keep that failure mode in mind, because it just disappeared.

Generation became free. Verification did not.

In early 2025 Andrej Karpathy coined "vibe coding": describe what you want in English, let the model write the code, don't look too closely. Collins made it a word of the year. Whatever you think of the practice, the economics underneath it are real and permanent: producing plausible code from a description now costs nearly nothing.

When one step of a pipeline becomes free, the bottleneck moves. The industry noticed within months. By late 2025 the fashionable term was "spec-driven development": GitHub's Spec Kit, Amazon's Kiro, Tessl, and a dozen others, all built on the same idea, that you should write down what you want carefully before the agents start typing. It is the right instinct. But look at the medium: every one of these tools has you write the spec in English prose and Markdown checklists.

English is a wonderful language for intent and a terrible one for specification. It is ambiguous by design; that is what makes it good at poetry and bad at contracts. Every English spec contains more than one program, and you find out which one you got only after the fact.

Vibe verification

A friend of mine put his finger on the next move. Verifiable software has always been a good thing that almost nobody paid for, because verification was even more expensive than coding. Now that agents write the code, he wondered, couldn't a second agent come along and write the verification? We joked that this would be "vibe verification." Then we realized the joke was load-bearing.

Here is the problem with it. If one agent writes the implementation and another agent writes the tests, and both work from the same English prompt, they are not independent. They can share the same misunderstanding, inherit the same wrong assumption from the same ambiguous sentence, and then confirm each other's bug with a green checkmark. Correlated failure wearing the costume of quality assurance. Testing only earns its keep when the oracle is independent of the thing being tested and unambiguous about what correct means. English gives you neither.

The formal-methods world has known the cure for decades: write the spec in a formal notation (TLA+, temporal logic) and check the implementation against it. There is a growing academic literature on pairing these with LLMs, and it points the right direction. It also runs into the same wall it always has: almost nobody can write those notations fluently, and nobody reaches for them at the speed of everyday work. The gap between English (writable, uncheckable) and formal logic (checkable, unwritable) has been empty for sixty years.

The ergonomic middle

Except it isn't empty. Iverson built the middle thing in 1962, and we have been sitting on it ever since.

An APL expression is three things at once. It is short enough to write at the speed of thought, which formal logic is not. It has exactly one meaning, defined by an interpreter, which English does not. And it executes, which means it is not just a description of the program you want, it is a running instance of it, usable as a test oracle.

avg ← +⌿÷≢     ⍝ the mean: sum down the columns, divide by the count
mavg ← {(⍺+/⍵)÷⍺}    ⍝ ⍺-wide moving average

That second line is a complete, unambiguous, executable specification of a moving average. Hand it to a coding agent and ask for production Python, and you get NumPy with edge handling, type hints, and a docstring. Now run both on a thousand random inputs. The notation was written by you and runs on an interpreter that has been settling arguments about its semantics since before you were born. The Python was written by a machine five seconds ago. When they agree everywhere, you have real evidence. When they disagree, you have caught precisely the class of bug that vibe coding ships. The demo page walks a concrete case where the agent's plausible-looking first attempt fails the oracle.

Note what the pitch is not. It is not that terse code saves tokens; the evidence on that is mixed at best, and recent studies suggest aggressively compressed input can make models work harder, not less. Conciseness is not the point. Checkability is the point. The notation earns its place because it is the shortest thing a human can write that a machine can also execute as ground truth.

Notational coding

So here is the pattern, and since vibe coding got a name, this one gets a name too. Notational coding: the human writes intent in a concise executable notation; agents expand it into whatever the production stack requires; the notation stays alive next to the generated code as its specification and its test oracle. Spec, source of truth, and regression suite, in one line you can read over the phone.

Notice what this is not. It is not a new programming language; the last thing the world needs is another one, and a language is 80 percent community, which cannot be willed into existence. It is not an APL revival for production systems; your code still ships in Python or C# or whatever your team maintains. The notation is the layer above, the blueprint that stays on the wall after the building goes up.

There is a fine old tradition of languages finding their killer application far from home. Java was built for embedded appliances and ended up running banks. APL was built to describe algorithms to humans, on blackboards. Maybe its second life is describing algorithms to machines that write the boring code for us. Same job, sixty years later: it was always a notation for telling something else what to compute.

What would make this real

Three artifacts, all small, all in progress here. First, the loop: a worked end-to-end example of notation, agent expansion, and interpreter-as-judge, with a real caught bug. Second, the notation page and agent kit: the small working subset of APL this uses, plus a reference document you can paste into a coding agent's context, because models write APL badly from memory and well with the rules in front of them. Third, a runnable notebook, since a spec you can execute belongs in a medium built for executing things next to prose.

That is the whole project. No roadmap theater, no Discord, no foundation. An idea, a demo, and a kit, finished by design. If the idea is wrong, the internet will say so quickly. If it is right, someone with an army will pick it up, and this page will be the receipt that says when and where it started.

Sources and further reading: Iverson, A Programming Language (1962) and Notation as a Tool of Thought (1979 Turing Award lecture) · Vibe coding · GitHub Spec Kit, Amazon Kiro, Tessl (spec-driven development, all English-medium) · LLMs and formal specifications (survey) · Beyond Human-Readable and Notation Matters (why terseness alone does not help models) · Token efficiency by language (J and APL data points).