Custom Lisp hijinx

I answered a few questions that were asked on TIGSource about how my custom Lisp works and why I made it. Sharing those questions and their answers here, too!

Yeah, I've had automated tests set up on the language itself from very early on. I'm not the best at writing tests for features BEFORE I find problems with them, but I do cover every new bug with a test. The snippet from the last post is actually a real, working test case. (When I first posted it, the test case had a bug in it, but I didn't know that until I fixed the bug the test was testing! After I caught it, I sneakily edited the bug out of the snippet in the last post.)

I have the language tests running automatically via GitHub actions, testing my language for platform-consistent behavior when Haxe compiles it into C++, Python, JavaScript with NodeJS, JavaScript without NodeJS, and when it interprets the code as Haxe directly. I'm only compiling FLIES FLIES FLIES into C++, but I use my language (Kiss  ) for tons of other projects like Visual Studio code extensions, the Firefox extensions I mentioned I'm using to scrape the authors' metadata for free assets I use, etc. which is why I don't just test as C++. I used to test for C# because I was actually integrating my language with Godot's Mono runtime (and it was working!) but I gave up on that because the Haxe team doesn't offer much support for C# compilation.

Here's the most recent test run. I don't know how much of the output is publicly visible, but hopefully it shows green at least. 

In between the language and the game, there are 4 libraries I'm writing that have their own separate repos. Two of these libraries interface with HaxeFlixel to make the game itself, which makes them very hard to test automatically. They do have some tests in them that I have to run manually from my computer. One of them (hollywoo) is hard to test because it actually defines an interface (i.e. a set of functions minus the implementation) and backend for the visual novel aspects of the game. So it's hard to test because it doesn't actually do anything without the HaxeFlixel implementation library (hollywoo-flixel). I was adamant about wanting to keep the VN logic separate from the specific manner of displaying text, sprites, sounds, etc. to the player. If I ever decide I don't want to use HaxeFlixel anymore, I can "just" implement a hollywoo-x frontend for whatever engine I'm replacing it with (as long as that engine can be programmed in a Haxe target language). And I have developed certain gripes with HaxeFlixel that make me kind of want to do a hollywoo-sdl implementation, but I don't think we're at that point yet. (And I think HaxeFlixel will be easier to take to consoles, web, or mobile, than SDL--not saying I plan on doing that for this game though).

My (private) game builds are automated with a GitHub action that compiles for Windows, Mac, AND Linux, and pushes those builds all the way to Steam! I only do this for milestone builds because the repo is closed-source so each build costs github action minutes. I thought I had already devlogged about this, but I checked back and I guess I didn't!

You are on the mark in that I am very prone to reinventing the wheel and then discovering someone else already did it. For example when I was almost done automating the Steam builds, I found an entire github action for it here that could have saved me the trouble. But, specifically regarding other Haxe lisps out there, I did do the research and didn't find any mature, actively maintained ones. And here's a point of pride--today, the top google result for "haxe lisp" in a private window is one of mine.



True to form, though, that's not Kiss, it's the Lisp that I abandoned years ago

Even with a lack of mature options to use, "are you doing this just for the fun of it?" is still a very valid question. I got into language design because as a lifelong writer and student of rhetoric (I even got a degree in it!) I subscribe to the idea that George Orwell expressed in 1984, which is that the language you use creates the boundaries of ideas and experiences you can have. And that applies to programming, too. I wanted the power to expand and define the boundaries of my own coding--and to weave my writing and coding closer together, potentially unifying them into the same language somehow.

But for all the grandiose dreams, mind-bending learning, and pride I've accumulated in the work...
Based on my experience and anecdotal evidence, it seems to me that if you decide to do any given project by making your own programming language, the practical cost of that choice is that the project will either flounder quickly, or take an extra 4 or so years to complete. And the reality is that 4 years also equates to a lot of money spent and life missed out on. I haven't refined the "4 years" number with data or statistics or anything--but in my case it's roughly that. Also, my projects now have a ridiculously high "bus factor" and I can't even really enlist or hire help with them now, which sucks.

Not saying I regret my choices, but yeah. 

This video recently made its way to my inbox:

It's not Rust, but I think making my own Lisp puts me in the same category of ridiculous buffoonery as the video mocks. And I'm okay with that.