Axis · the language
Keep the meaning. Work the steps out from it.
Everything we build keeps the steps and throws away what they were for.
This is about keeping the meaning instead — and what changes, all the way down, when you do.
Every program ever written is a list of steps. Put this here. Go round that. Check whether this is empty. Call that, and hope it does what its name says.
What the program is for is never written anywhere a computer can read it. It lives in someone's head, in a comment, in a document nobody updated — and in the one person who was there when it was built. When they leave, it leaves with them.
So a great deal of what we do afterwards is guessing it back. Checking tools guess at what you meant from the shape of what you wrote. Reviewers work it out again by eye. Documentation writes it down by hand, and is out of date by Friday. All of that is effort spent recovering something we threw away for free.
This turns that round. You write down what you mean, and the steps are worked out from it — the way a map works out a route from an address, and finds another when a road closes.
Three rules make that possible, and underneath all three is one idea: nothing hidden.
Nothing is changed once it is written. You never alter a value; you make a new one. There is no "current state" that can quietly go wrong behind your back. And a new version is not a copy — it shares everything that did not change, so changing one thing in a long list costs one thing, not the whole list.
Things are known by what they are, not where they are kept. Seven is sept, sieben and nana, and it is still one seven. Here too: write the same thing twice, with different names, in a different order or a different layout, and it is recognised as one thing, not two. It cannot catch every pair of things that happen to mean the same — nothing could — but it never mistakes two different things for one.
Reaching out into the world goes through one door. Reading a file, sending a message, asking the time — none of that can happen from inside your program. It has to ask, and everything it can ask for is on one list you can read.
It is the bit everything else hangs off, so it is worth a minute.
Sort everything a program does into two piles.
Working something out. What is 20% of this invoice? Is this name already on the list? Put these in order. Nothing outside is touched or asked. Do it twice and you get the same answer twice.
Reaching out. Either asking the world something — what time is it, what is in this file — or changing it: save this, send that, print it, open the gate.
The test is simple: run it twice. Same answer both times, and nothing outside is different afterwards? That is working something out. Anything else is reaching out.
In every language you have used, the two piles are shuffled together and nothing keeps them apart. A piece of code called format the name can also delete a file, and you find out when it does. Here they are kept apart by construction: your program can only work things out, and anything that reaches out has to go through the door.
That door is called the bridge. It is the one place where meaning turns into something actually happening.
Because everything has to come through it, the hardest parts of computing only have to be solved there — once, properly, by people who care about getting them right — and every program above it gets the answer for free.
The best example is the one programmers have the most scars from: getting a computer to do several things at once. Today it is one of the hardest parts of the job and the source of its strangest bugs, the kind that only appear under load, on one machine, at four in the morning. Here it is one word on a piece of code. Nothing can be changed underneath anything else, so there is nothing to fight over.
The same goes for talking to devices, to the network, and to other people's code. Fix something in the bridge and every program built on it is fixed — last year's, next year's, and the ones nobody has written yet. Today that knowledge stays in whichever team happened to solve it, and the team next door starts again from nothing.
See it work: one word, and it runs at once →
Yes. That is the point. Today the hard part is everywhere, mixed in with everything else, solved a little differently — and a little wrong — in every program. Here it moves to one place, where it can be looked at properly, tested properly, and fixed once.
And the bridge is not set in stone. What your program means stays the same; the bridge underneath can be replaced with a better one, and nothing above it has to change.
Here is the part that took longest to see, and it is the biggest idea in the whole thing.
A bridge does not have to be the one that runs your program. A bridge is anything that reads the meaning and does something with it. Write the meaning once, and point as many lenses at it as you like.
Read it for a different machine. Today one bridge turns it into something a computer runs. Another could do the same for a phone, a browser or a small chip — and they would not be two programs that happen to agree on their tests. They would be the same program, read two ways, with nothing to drift apart from.
Read it without running it. What can this program touch? What will it cost? Explain what it does. Today each of those is a separate tool with its own partial guess at your code. Given the meaning directly, each of them gets simpler, and none of them has to guess.
Read things that are not programs at all. A stream of payments. Readings off a sensor. A pile of policy documents. Write down what they mean once, and let five different readers look at the same thing — one for fraud, one for anything unusual, one for the rules, one for cost, one for where it came from. Where they disagree is itself worth knowing.
Fixed memory alone is a record nobody can read. Meaning alone drifts when what it describes changes. Together, every meaning points at a value that can never move.
So a result can be reproduced, traced back to exactly what produced it, and changed safely: a change is a new thing beside the old one, and the meaning says what it touches.
It can tell you what it is able to do, before it runs. Not a scan and not a guess — the list falls straight out of what it asked the door for.
A call to something that does not exist cannot be written. It is caught the moment it is written down, not discovered in the middle of the night.
Labels that cannot fall off — designed, not built yet. Mark something as private, and it stays private through every step, because the mark is part of what it means rather than a sticker on the outside. A route that would leak it is refused before the program is ever built.
"We don't know" is a real answer. When the system cannot tell, it says so, and something has to decide what happens next — instead of a confident guess, or a blank that crashes later. Knowing where you don't know turns out to be worth more than a best guess.
Nothing is stored twice. The same thing is kept once and recognised everywhere. If the far end already has it, there is nothing to send.
You cannot change things in place. Most of the time that is the point. But some jobs really are "change this, here, now, within a fixed amount of memory" — video and sound, very tight number crunching, hard real-time control. Those are a bad fit by design. Use the right tool there.
Someone still has to say exactly what they want. This takes away typing out the steps, not thinking. If you cannot say what "right" looks like, nothing here can help you.
Everything rests on one idea. That is what makes it simple, and it is also the risk: if the idea has a crack in it, the crack runs all the way up.
It is new. No track record, no certification, nobody to hire who already knows it, no answer waiting for you online at two in the morning. That is a real cost, and no amount of good design pays it off early.
So not for anything with a hard deadline, anything safety-certified today, or a plain app that already works. Existing tools are mature, cheap and good enough there.
Almost every piece here has been proven somewhere already, and that is deliberate. Git keeps everything by what it is rather than where it is. The Linux kernel lets readers carry on while a new version is published, so nobody waits. Erlang has run telephone networks for decades on values that never change. Security researchers worked out fifty years ago how to make labels travel with data.
Each of those works, and each stops at the edge of its own corner — one tool, one language, one layer. What is new is putting them in one stack, all the way down, and not stopping at the edges.
The bet is that most of what we put up with as permanent friction is just the gaps between them.
None of what follows is built. It is where the same few ideas lead when you point them at something other than a program — worked through, one field at a time, over the last year.
Computers and chips
Talking to each other
The web, and the things on your screen
Keeping things
Safety and trust
Rules, money and institutions
Beyond computers
Everything it might reach, field by field →
The language and the bridge are built and run today, and so is a database written in the language, which ordinary database tools can already talk to. The bridge is under a hundred things it truly needs, and you can print the list — it is being made smaller on purpose. The rest — the operating system, the screens — is designed or under way, and the pages underneath this one say exactly which is which.
The whole project is public on GitHub, one repository you can read today: github.com/christaylor98/axis.