The Blæst Programming Language

Postmortem and About

I always hated how condescending this page sounded, so here is a much better explanation of what Blæst was. You can view the old page here

Blæst was my first proper foray into writing a programming language. I always referred to it as a compiler, but in all honesty it was a little more than that, taking heavy inspiration from the Java Virtual Machine (JVM). Blæst was based off of the B Programming Language, which at the time I thought was an amazing programming language, as instead of having all the complexities of C with typing, it was effectively a dynamically typed C, with the added benefit that there was only one type. Currently Blæst's source sits on Github. I may eventually update it, or maybe remake it. I still do like it and like the idea, however I now acknowledge that its nothing new, and won't change the world.

What Went Wrong

What went wrong is a loaded question for Blæst. First of all, consider that most, if not all of the code was written by me, a dumb 18 at the time kid who had never taken a single Computer Science course, let alone any on compiler theory. From the word "go" I basically wrote the entire compiler with very little knowledge of what I was doing. The parser, if you can even call it that, is housed in a massive, over 1,000 line function which takes 20 arguments (I guess I didn't know about or didn't want to use structs at the time), and is extremely inefficient. At the time I wanted to not use a parser generator since I considered that cheating, however now, I realize if I consider that cheating, I could just write the parser generator, and suddenly the parser becomes much easier to manage.

Apart from the parser, the actual lexing of the syntax was extremely poor. I believed that reading over a line of code more than once was a sign of an inefficient parser or lexer. While this may be true of some programming languages, especially assembly languages which were the only languages I had experience writing, this was definitely not the case for languages such as C or B. Part of this is why order of operations never worked in Blæst, and also why some things like preprocessor macros aren't actually preprocessor. To make them preprocessor would require that I read the file more than once, something I refused to do.

Aside from the parser/lexer, the actual code generation of the compiler was horrid. Instead of doing a pass of the source code to pick up and define global variables (or even just keep track of globals being used). I decided that the full name of the global should be written to the code generation buffer to be later resolved. What seems to be the issue however? Well, Blæst used a lot, and I mean a lot of absolute offsets in code. Meaning if you made an if statement, to branch past it would be absolute, as well as the conditions. A relative jump instruction did not exist in Blæst. This is a problem since one the global is resolved, its size in memory would only be one word, which is what all values were sized to in Blæst, however the actual name of the variable could be multiple words. This meant that two independent indexes needed to be tracked. One for the actual position to add new characters to the buffer, and one for the position in the buffer once the globals were resolved. Awesome right? This lead to a lot of confusion and headaches when positions would be off, and the worst part was this could be caused by literally anything. If any part of the code gen increased (or more likely forgot to increase) one of the indexes, there was a high possibility that it would break every other part of the generation, leading to hours of trying to find which exact part was causing issues. This was one of the reasons why development was so slow.

Despite being extremely knowledgable in C, and even knowing best practices when working with memory and buffers. I didn't reallocate any buffers in Blæst. Why you may ask. Well, just because I was "rapidly prototyping" everything, which apparently means good practice can go right out the window. While I did free memory (at least I think I free'd memory), I did not expand it when it would reach the end of the buffer. While this didn't effect most of the test programs I was writing at the beginning, the minute I started using Blæst as a true programming language was the minute things started breaking. I always blamed these "bad write" errors on whatever operating system was being used. "My program crashed on Windows, must be a Windows issue." After this started happening however, other parts of the compiler were having their memory overwritten, for example, I believe the variables part of memory started to have garbage data written to it since the code generation buffer lived right beside it in memory, and that thing constantly overflowed. Because of this, I have to say, use EXTREME caution if you ever go out of your way to try Blæst.

In Closing

If you want to use a programming language I have developed, please go check out Crow. It was developed out of caution from ending up like its predecessor. Fair warning however, it is not like Blæst at all. Personally I learned a lot from the Blæst project, mostly how a language works from the ground up. But just because it was a good learning step doesn't mean it was a good program. The source code remains on Github to this day, and I don't wish to take it down. If you can learn something from it, its done its job. But if you really want to see a comeback of the B programming language, just make some preprocessor macros for C, most compilers actually implement them correctly. And who knows, I might restart development on Blæst when I get bored some day.