A Node.js-based Bard Compiler

I'm writing a new version of the Bard compiler in Node.js, the popular and convenient Google Chrome-based standalone JavaScript engine that's available as an easy, standalone install on every major desktop OS.

Not only will that make distribution and installation super easy, but it will allow me to add support for Bard source code-level blocks of JavaScript code that can be used as a meta-language to tweak the program at compile-time. Similar to how JavaScript is traditionally used to generate additional HTML and manipulate the Document Object Model of a web page, the Node Bard Compiler will be able to generate additional source code and manipulate the program data structures before code is generated by executing JS embedded in your source code - even to the extent of adding new project-specific keywords and data structures!

I'm changing up the design philosophy of Bard as well. As I mentioned in my initial Unity post, many of my reasons for originally making Bard are no longer as valid and there's really no need for another full-blown Slag/C#/Java-style "self-contained high-level language platform". As I started playing around with Unity though, I immediately wished that the game state logic for all of our previous Plasmaworks games could be easily ported over to C# to be paired with a new Unity-based renderer. At the same time I'd been writing a lot of straight C code using a object-oriented style (e.g. "ArrayList* ArrayList_add( ArrayList* list, void* element )") and growing increasingly frustrated with how much tedious boilerplate was involved in expressing simple OO concepts in a procedural language. In addition I'd been getting into and was really impressed with CoffeeScript and Iced CoffeeScript, both of which translate a much more elegant form of source code directly to JavaScript.

At that point I realized what I wanted to do with Bard: I want to make Bard a more conceptual, more abstract, more modular "prime" language that cleanly translates (cross-compiles) to other languages as a fundamental behavior - an "ergonomic translated language". I'm going to make Bard a more perfect "pseudocode language" at the cost of universal portability when necessary. For example you'll be able to use pointers in your source code but you'll get errors if you try and translate that source code to a target language that doesn't allow pointers. Or likewise you can use garbage-collected objects and those won't incur an overhead when translating to C# or Java but they'll require a Bard Object Manager Library to be linked in if you translate to C/C++.

More details to come!