This article is mirrored on my blog.

I started working on Cakelisp a little more than a year ago. I started the project after searching for a programming language that met all my requirements, and found nothing which matched.

I figure this is a good time to take stock and talk about what is in the future for Cakelisp.

Popularity

My goal was never to make a language that everyone wanted to use. I always approached Cakelisp with the goal of making the perfect language for me, without considering too much how other people would like it.

This gives me a whole lot of flexibility when making decisions. I can play more fast-and-loose and make big changes without worrying.

Besides, even if I did try to make a language for "everyone", I believe I would have failed to get much more attention.

As it stands, Cakelisp has over two hundred "stars" on GitHub. My original Hacker News thread got a few hundred upvotes, which is relatively good for Hacker News. I get emails maybe once every three months or so with questions about Cakelisp.

I think I'm still the only person in the world using the language. I think this is fine for several reasons:

• I can make changes without worrying about breaking other peoples' projects.
• I don't feel a lack of existing libraries. I have easy access to essentially any C or C++ project, which is a massive ecosystem. GameLib shows how easy it is to expose C/C++ libraries, and still with no bindings necessary!
• Supporting a language used by many people quickly becomes a full-time job. By staying small, I can focus on my goals rather than spend too much time helping other people with their goals.

If you are interested in using Cakelisp, don't let this deter you. Because the language is so small, it means you can have a big impact on the direction of the language, and can make big changes yourself without much trouble. I think even though general applicability wasn't my goal, the language is still useful in a variety of cases, and is appealing not only to me.

Purpose

It is important for me to clarify that I never made Cakelisp for its own sake. I was running into real pain points with C++ on my personal projects, and made Cakelisp to alleviate that.

From that perspective, I consider Cakelisp a great success. There are several angles I see where the language succeeded.

I am more motivated to write in a language I made, because I can tailor it to my tastes. This is very eye-opening. At my job, I now realize just how much pain is caused by using C++, and I know how "easy" it would be to stop experiencing that pain. When you like your environment and have control over it, you are much more productive. Things don't feel arbitrary, and you are empowered to make changes at every level.

I no longer need to futz with 3rd-party build systems, which never seemed to work exactly how I wanted. Admittedly, I now futz with Cakelisp's build system[^1], but we all know we're much more forgiving of our own projects than other peoples'.

Projects

The language was never the end goal, making projects with the language was the goal. I have successfully made several projects, including an Android game for my girlfriend:

...a file organization application for sale:

...an automatic color scheme generator:

...and various other prototypes.

GameLib provides me with easy access to a huge amount of awesome C and C++ libraries. Each time I add a new module to GameLib, all my future projects benefit from how easy it is to import. GameLib handles acquiring the 3rd party source and versioning, which was a noticeable point of friction for me that prevented me from making quick prototypes.

Plan

I have no intention of stopping using Cakelisp. It continues to provide value every time I start a new project.

In terms of major updates to the language, I don't have anything explicitly planned. I let my projects dictate what needs to get done on the language. I have about 2,600 lines of TODOs and various notes on Cakelisp in my personal notes, so there is no doubt work to be done, but it doesn't really need to get done if I can still successfully ship projects without them.

I have been itching to move towards pure C output support. This is valuable because it should speed up compilation times, make embedded systems programming in Cakelisp more reasonable, and I like the elegance of C over C++. The barrier here is mostly compile-time code execution, because a lot of Cakelisp's public APIs use C++-only features like generics (std::vector and std::unordered_map) and std::string[^2].

This change will require a relatively large refactor of both the compile-time APIs and the build system interface. I'm not sure when exactly I will get to it, but it will be nice once it's done.

Conclusion

I'm very happy with Cakelisp's progress and what I've been able to get done with it. I am not concerned by its lack of popularity, because that wasn't a goal of mine. I plan to continue refining the language and making cool projects with it. Here's to another year of Cakelisp!

[^1]: Which, to be fair, is much simpler and more limited than something like CMake, which is more complex and riddled with features. (To put it out there: I hate CMake so much, but that's beside the point. Don't use something just because everyone else is using it, etc. etc.)

[^2]: One of my biggest regrets now on Cakelisp is using std::string. It no doubt saved me time getting started, but I'm going to pay a much bigger price now trying to get rid of all of it. If you find yourself making a language, do not use it! Write a string interning system or at least your own linear allocator instead, and keep your APIs C-compatible!