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.
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.
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