2026-05-26
Over the past few days I've spent a lot of time thinking about programming languages. What do I want out of them? How do I think they should work? Do any of the existing options meet those criteria? That kind of thing. So here is a ramble about what I want out of programming languages.
First, I think a language is harmed when it tries to cover too many use cases, or do too many things at once. Rust, for example, is trying to be high-level and low-level at the same time. The versatility this provides is useful, to be sure, but it means that when writing high-level applications you're forced to think about details like move semantics and lifetimes. This complicates the process of writing Rust software, and also means Rust itself is not as simple to implement as it could be. The trade-off, of course, is that you gain access to those high-level features in low-level Rust, and that every application written in Rust is resource-efficient by default.
The main area where this conflicts with my needs is in the realm of permacomputing. For that, I want simple languages, capable of being understood and hacked on by a single person. Modern industry might benefit from a language with "batteries included", but it also means that the language cannot exist without the support of that industry.
Hare is a language that seems to meet this concern, designed to remain small and simple, and using the "hobby-scale" backend QBE. Having worked with Hare, however, I feel that it both does too much and not enough. It's simple, sure, but the complexity it does add doesn't feel like it buys you much, it's still a pretty bare environment to work in.
Haskell is another language I've looked at. It's this beautiful, elegant core of a language kneecapped by a preponderance of features, a significant divergence between best practices and the standard library, and generally unimpressive performance from compiled code due to its runtime and garbage collector. Its origins as an academic language to study lazy evaluation ends up really hurting attempts to actually use it; it turns out lazy evaluation is only a good idea in a few scenarios.
All of this has led me to conclude that my ideal programming language needs to actually be two programming languages designed to interoperate well. The first would be a low-level language with minimal abstractions, just enough features to help the programmer avoid common footguns. The second would be a functional language with an expressive static type system, automatic memory management, and full metaprogramming enabled by homoiconicity. Calling the low-level language from the high-level one should be effortless. Let each language do one job well, rather than writing one language that tries to do both and suffers for it. And crucially, the high-level language should be adaptable via macros rather than try to integrate every possible feature a particular use case might need or want.
I'd like to design and implement a pair of programming languages fitting this description! Once I have a cohesive idea how they'd work, I'll post the rough outline of the design.