Simpler


Simpler

I started programming on calculators in the late 70s. Always fascinated with the HP-41 that came out in the 80s. Did a huge number of projects on that beauty, including lots of Assembly programming. That led me to create the XRPN programming language back in 2022 - an extension to the RPN language of the HP-41.

But I have been toying with the idea of a really simple programming language since the mid 90s. A week ago this idea came creeping back in and bit me.

Since a while now I have been replacing the tools I depend on with tools I control. A desktop in assembly, a shelf of Rust programs, lots of phone apps. Through all of it I’ve had one buddy: Claude Code. I describe a change, it writes the code, and the itch is usually gone before I finish the sentence. I program in English these days.

So I write a great deal of code with an AI now. And every language I write it in, Rust, Ruby, Kotlin, was designed for a human to read and recall. The AI is fluent in them because it has read millions of examples. It made me wonder what a language would look like if it were built, from the first line, for the AI to write rather than for me to remember.

So I built one. It is called Simpler, and its only goal is to be simple.

The whole language fits in the prompt

An AI writes good code in a mature language by recalling the right idiom out of the ten thousand it has seen. It has seen none of mine. So the one thing that matters is whether the entire language fits in the prompt at once. Make it small enough and Claude holds all of it in its head. That makes for less guessing.

Simpler’s surface is tiny. Everything is a message send: a field read, a method call, an operator, all the same shape, receiver.name(arguments). Four pieces of punctuation. Seven operators. A single page of built-in methods. The spec is IT, and you can read the whole thing in one sitting.

It outputs C and hands that to the system compiler, so it is fast and runs everywhere a C compiler does. No garbage collector, so no pauses and nothing waking up to burn battery while the program sits idle. No borrow checker, so there is nothing hard to learn. Effects and permissions live in the function signature, so a function can touch only what it was handed, which kills the most common way AI-written code goes wrong: reaching for something that is not there.

It writes itself

The compiler is written in Simpler. It compiles its own source into C, that C compiles into a new compiler, and the new compiler compiles the same source again to a byte-for-byte identical result. A language that can reproduce its own compiler exactly is a language that holds together. I started creating it with Rust. Now it builds with no Rust at all.

On top of that I wrote a handful of real little Unix tools in it: a line numberer, a CSV column summer, a word-frequency counter, a sorter, an averager.

The test

Then I ran the one test I cared about. I gave an AI nothing but the spec, one file, with no sight of the compiler and no sight of a single example, and asked it to write a small statistics tool: count, min, max and mean of the numbers you feed it. It compiled and ran correctly the first time. It even handed back an honest list of the few places the spec had left it guessing, and I folded those back in.

The spec was enough. That was the whole idea. The language is small enough that an AI can learn all of it from one page and write it correctly, with nothing memorised in advance. Leaning on NO training for that language.

Why bother

Same reason as all the rest. I would rather understand and own the things I use than rent them. But this one has a twist: I mostly describe what I want now and read what comes back. Simpler is the first tool I have built where I am not really the one meant to write the code. The machine is. I just had to give it a language small enough to hold.

It is version 0.1.0, public domain, and it compiles itself.


Link to this post: https://isene.org/2026/06/Simpler.html