Notes
2026/02/08
What's the goal of building a programming language, or any software really? That depends on how many innovation tokens you want to (and can) spend. Some programming language are meant to be useful and pragmatic, deliberately choosing familiar concepts over experimental features. Some programming languages are meant to be test beds for new ideas, prioritizing the exploration of concepts over mass adoption.
The first category are projects, meant to ship useful code. The second category are experiments, meant to explore ideas. Success is measured differently for each category: Projects try to disseminate useful software, success is measured by shipping useful code. Being novel can be an afterthought. Experiments try to disseminate ideas, success is measured by validating ideas. The code is merely a tool for sketching out the underlying ideas.
It's hard to build something that is both a useful project and a successful experiment, because these approaches are often at odds. Trying to build a programming language that is both useful and explores a combination of experimental features rarely goes as planned. Well, it certainly would have been nice to realize this before trying to build a programming language.
Going over the list of projects I had been working on at the Recurse Center, it struck me that Slayerfest neatly fell into the project category, whereas my explorations of time loop maps definitely count as an experiment. But Kombucha, the language that I spent most of my time at RC on, awkwardly sits between project and experiment, being not quite useful, but not a clearly scoped experiment either. I even wrote about how Kombucha felt like a series of experiments, but that didn't really lead me to change my approach. I realized that Kombucha was trying to combine several experimental features, but I just hoped for the best.
The problem with approaching a project as a series of experiments is the interaction of the various features. In terms of innovation tokens, a combination of experimental features is more than just the sum of them. Sounds obvious. (Maybe it is?)
What's the takeaway for Kombucha? Instead of trying to build one experiment on top of another, I might try taking a step back, literally, by ripping out Kombucha's more experimental features and starting with a really boring, really simple language. All the various experimental features (the syntax, the macro system, the effect handling, the partial evaluation) will become separate experiments. Only after validating and experimenting with each feature in isolation will they make their way back into Kombucha. Or now, in which case the outcome of the experiment is still an interesting bit of code that can live on its own, instead of withering away somewhere in Kombucha's commit history.
Let's see how it goes.