A Story of a Cherrycake… One that Keeps Getting Remade and Rewritten.

Around this time last year, I wanted to build a programming language. It was a large task but I decided to commit myself.

Me, suddenly getting called by Cherrycake.

The first version was thrown together in Javascript and did not work. The same went for the second and third versions as well. I quickly found that there are only a few people who have ever built programming languages, and even fewer who have documented the process.

This lack of learning resources forced me to do something hard… stop and think. I drew out the language compiler as a machine, and split the insides into several parts: tokenizer, parser, tree shaker, etc.

I then got to work, building every part incrementally and testing each one individually. The final language compiler was done, and had features that I was quite proud of.

With a single command, I could generate documentation for an entire file of code– saving me hours of boring work. With just another command, I could ‘beautify’ my code– making it more readable and concise.

There was only one problem: I could run the code in interpreted mode but I could not compile it. To provide a half baked metaphor: compiled code is like sheet music– it’s pre-written, optimized, and efficient– whereas interpreted code is like improvisation– it’s dynamic, real-time, and can be played with anything.

After this problem came a bigger one– I had other projects to work on.

I’m not saying that I was not proud of what I built. In just a month, I joined a list of ~600 people in human history who have designed their own language– I was incredibly happy. And, much more important, I broke down a complex task and persisted– with a finished product in the end.

And a year later– Now, I’m coming back to it. I’m doing something incredibly stupid and hard… I’m building Cherrycake in Cherrycake. I’ll be documenting the process in a simple-ish way on the blog, and hopefully will have a finished version soon.

My experience moving from a junior to senior developer.

I wrote down this story because I think it’s a nice anecdote and something I did not understand when I started programming– planning is always more important than doing, as doing is the hardest part. So hopefully, if a new programmer reads this, they can learn quicker than I did.

Cheers,
William McGonagle