Oak

Oak is a rust-like language built on esoteric-inspired architecture. It was conceived as an alternative to C according to creator Adam McDaniel:

I wanted a language that had all the elegance of C, such as the potential simplicity of the intermediate representation, without all of the things that make C ugly and dangerous. I added stricter type checking rules to prevent simple memory errors, and a lot of the ugliness and difficulty of writing C code went away.

Its tiny back-end, built on experiments with brainfuck, is "infinitely more portable" than C. Even the smallest C compilers, designed for highly constrained environments, have around twice the number of opcodes that Oak relies on.

Oak relies on a series of earlier experiments. Like many who dabble in the esoteric arts, McDaniel began with a brainfuck variation. SMPL, written when McDaniel was in high school (he is only a college freshman now), extends brainfuck by three new commands; each is, of course, represented by a new punctuation symbol:

While most brainfuck extensions run counter to the minimalist constraints that make the language interesting, this was done less with writing SMPL as the end goal, but building a more conventional language on top of it. By adding pointer manipulation of this kind, he could now perform dynamic memory allocation for the language he would write on top, free. He aimed to make free more powerful than brain-lang, which also generates bf but lacks free's type checking and the dynamic memory allocation made possible by SMPL.

Free's syntax is similar to Rust (McDaniel bases this choice on "the objective fact that rust is the best programming language ever made"). But the fun of free is seeing the SMPL it compiles down to. There is even a brainfuck-compatibility mode for debugging with existing bf tools (although it turns off pointers and reduces memory cells back to bf's default of 1 byte). McDaniel drew from the esolang wiki's brainfuck algorithms page to make much of the compilation possible, building on the work of bf enthusiasts who have similarly enabled performative brainfuck projects (remember the brainfuck web server?).

However, free seemed to run out of its creator's control and luckily for us, McDaniel puts this on display for our edification. First, the SMPL it generates contains long lines of un-optimized increments and some confounding sequences were hard to understand. Secondly, computing stack allocations, one of the more complex aspects of free's compilation, backfired, leading to a messy process: he ultimately added a warning that the language seems to work as if by magic. In retrospect, he decided the stack could have been kept at a static size, avoiding that complexity:

I hate myself for implementing the stack this way. Never do this. Just implement push and pop and be done with it.

McDaniel ultimately tagged free with the glorious description of "a terrible programming language that targets an even worse programming language."

Then, I had an idea. What if I kept the tape memory structure from Brain****, kept the memory management operations from free, and added some operators for managing a stack?

This inspired approach led to Oak's backend. Rather than simplifying, McDaniel took an even more ambitious route, with higher-level code. He kept the tape memory structure from brainfuck (with doubles rather than ints) but replaced brainfuck's command list with the seventeen instructions McDaniel found essential, all of which are more traditional opcodes. The compilation process is explained very clearly here.

It is again framed as a C alternative:

I would say it's a middle ground between C and C++. It supports structures, but not classical object orientation with inheritance. These structures have methods, members, associated functions, copy constructors, destructors, etc. Also, Oak's preprocessor / compiler flag system is something I'm very proud of. I feel like Oak is a significant improvement upon C.

After completing Oak, McDaniel has turned his attention to a more purely functional style, an idea he explored previously (as a high school sophomore) in Maroon-lang. His new language will perhaps be for Maroon what Oak was for free, a completely new approach building on the most promising aspects of his previous idea:

The concept of lambda calculus is something special because it's completely self-contained: almost like it's eating itself. Everything is a function, including the lambda expressions themselves, applications of lambdas to other lambdas, etc., and it's absolutely beautiful.

My new language backend will use fixed-point combinators, which are special types of functions, which are turing complete together, that allow users to transform their lambda calculus expressions into expressions with no named variables. This is incredibly useful as a compiler writer, because there are no variables to store! The only mechanism needed for computation is the ability to apply various combinators to one another.

However, we will likely see new work building on the ideas in Oak as well:

I'm very excited to see the direction this style of compiler design takes me.