Semantic blocks

Motivation

English is shaped by the fact that we invented it for talking.

Speech is a strictly linear channel. One word at a time, in order, in real time, with no ability to look ahead and no ability to go back, and the listener has to decode it as fast as you produce it. Every feature of natural language grammar is fitted to those conditions. The structure is loose and fuzzy because it has to survive being generated on the fly, and it is redundant because the listener gets exactly one pass at it.

Text is not that channel. A page sits still. You can see a whole paragraph at once, glance back at the sentence before, skim forward, and hold structure in front of your eyes instead of in working memory. I called it a 1.5-dimensional medium in my notes at the time, meaning more than the single line that speech gives you and less than a full plane: enough that you can take in more context at once.

So we are writing in a notation designed for a channel we are not using. That mismatch is cheap to state and turned out to be worth a week of November 2023.

The pidgin

If English is under-structured for text, you can add structure to it. Not replace it with a programming language, which throws away everything English is good at, but augment it with constructs the spoken channel could never have carried.

My note calls this a vocabulary of semantic blocks, for expressing ideas that are less obvious when encoded in plain natural language, and describes the result as an augmented English, a pidgin between English and a programming language.

The word pidgin is doing real work there. A pidgin is what appears when two groups need to trade and neither language will serve: it borrows from both, it is simpler than either, and it exists for a job rather than for a culture. That is the right shape for this. It is not a formal language with English-looking syntax, and it is not English with some annotations bolted on. It is a third thing that exists because two parties need to exchange something neither notation carries well.

What the blocks actually are, I did not settle. The note is a paragraph, and the paragraph is a direction rather than a design.

Load-bearing representations

Within a few days I wrote down two more instances of the same thing without noticing they were the same thing, and the three together are worth more than the pidgin was on its own.

The first was about money. When you work with accounting in software you work with the codified low-level objects: a ledger, transaction entries, amounts and dates. People do not think in those. A person thinks in terms of a business expense, which is not a row in a table but, as I put it, a loose collection of related tasks, objects, entities and rules that hangs together in semantic space. So I sketched what I called an API for Human Concepts, where the operations exposed are themselves loosely defined, on the grounds that this is how two people actually hand work to each other.

The second was about types. Taking the cue from Mojo, Modular's superset of Python, I sketched the same move for TypeScript. The complaint driving it was specific: TypeScript's types are ornamental and do not influence runtime code. You pay the full cost of a strict and verbose type checker, you fix everything it complains about, and then the compiled JavaScript carries none of the guarantee, so what you bought was editor support rather than safety. That erasure is a deliberate design decision by the TypeScript team and a defensible one, because it is what lets TypeScript compile to JavaScript that any runtime will accept and what made it adoptable at all. It is still a cost, and it was the cost I wanted back. The design goal I wrote down was that types should exist on the same plane as real code, enforced at runtime and available to introspect before compilation, so that logic can depend on them.

English, a ledger schema and a TypeScript type are all notations carrying less structure than the job in front of them, and in the third case the structure is there and has been deliberately disconnected from what it describes.

The common shape is that a representation should be load-bearing. If a structure in your notation does not constrain, produce, or otherwise affect what actually happens, it is decoration, and you are paying for it in attention and getting nothing back. That is the same idea I had spent the previous two years on in a compiler, where the entire premise was making the language carry the constraint rather than the documentation. I had not connected them at the time.

Interrogating a design in writing

The same week's notes contain something about method rather than about language, and I have used it more often than any of the above.

I had been carrying an idea for a while about building editor extensions with a custom React renderer. React is the library most web interfaces are built with, and a renderer is the part that decides what the description of an interface actually turns into, so a custom one would have let me describe an editor panel in React and have it come out as something the editor understood. I sat down to make a proof of concept, then stopped and asked, in writing, whether the idea made any sense.

Answering it took four steps and I would repeat all four. I named what React actually gives you, which is JSX, reactivity and state. I named the domains where those pay off, which are markup like HTML or PDF, interfaces like React Native, and tree-shaped data such as a syntax tree. Then I checked my own case against that list and found that the strongest justification was rendering web views, and that web views can already use React's ordinary DOM renderer, so a custom one would not be necessary. My note concludes that it had mostly been an interesting angle to consider.

That is a subtraction test run on my own idea. State what the tool buys, state where that buying matters, check whether your case is one of those, and if removing the tool costs nothing then it was never load-bearing. Which is the same test as the one about representations, applied to a dependency instead of a notation.

What got built

Almost nothing, and it is worth being exact about it. The repository I made for the systems language that week has two commits, timestamped 04:58:49 and 05:14:12 on 18 November, fifteen minutes and twenty-three seconds apart, and a README containing the project name and nothing else. Every idea above lives in documents.

I noticed this myself the same day, in the same file, about a different subject:

noticing now that I've encountered the threshold of discomfort that exists between reading code — and feeling good about understanding it, delusional and not grounded in reality, and actually sitting down to write the code.

I am including that because the week is a clean instance of it, and because the observation about English and the oral channel is still the most portable thing I wrote down in 2023, and it cost nothing to have and nothing to keep.