I have been writing software commercially for more than thirty years, long enough to watch languages, frameworks and fashions come and go. Things have improved in that time, but for a while now we seem stuck in a loop: rehashing old ideas, rearranging the furniture, and calling it progress.
In the history of programming, only a handful of innovations genuinely changed how we work, each one by letting the programmer worry about less, and write far less code to reach the same end:
- High-level languages.
The move away from assembly language and punched cards towards something that tries to read like English, written for the programmer rather than the machine.
- Structured programming.
The first step up from assembly-like code into something you could actually reason about.
- Garbage collection.
Freedom from manual memory management and object lifetimes, and I would put Rust's borrow checker in the same family.
- Reactivity.
Letting the system deal with updates as data changes, instead of wiring every update by hand.
Even with all four, the current crop of languages and frameworks still leaves a great deal for a team to solve, and reinvent, on every single project. Three things in particular:
- State management.
Where does the source of truth live, and how do changes get wired back into it? Reactive frameworks give you the downward direction and leave the upward direction to you.
- Asynchronous handling.
Clunky at best, and code that deals with asynchronous values usually has to be written quite differently from code that doesn't.
- Multipurpose code.
Define a thing once, say an interface, and have it served as a web page, rendered to a texture on the GPU, or laid out as a PDF, without writing it three times.
I think there is room to take the next step, and I have been circling these ideas for a long time, slowly solidifying fuzzy hunches into something concrete and implementable. This has come from sheer practical experience, building many large applications, with whole teams, and watching how decisions actually play out years later, after hundreds of interacting features. Pure research can build a small example and stop at the interesting fork in the road; I have had to travel those forks and live with what is at the end of them. The most useful thing I have learned is that some of the best decisions are deeply counter-intuitive, and not the well-trodden path.
A couple of pleasant properties fell out of the way it is built, almost for free: a program and its state are simple enough to sandbox and snapshot - to lift a running program and continue it elsewhere - and the format is simple enough to be drawn and edited as diagrams.
What I am making is a high-level language for building real applications, not a systems language for wringing control out of bits and bytes. Over this series I want to build it up from first principles, so let's start at the beginning.