The Origin of Wasabi

October 31st, 2007 by Stefan Rusek

As the primary developer and maintainer of Wasabi, I've wanted to write a series of articles on Wasabi for awhile, and last week, I decided to talk to Joel about it. Today, I will start off with a short history of the language, and later, I will talk about some of its cooler features and where we want to take it in the future.

Several years ago Joel and Michael decided that they wanted to have a Unix version of FogBugz. At the time, FogBugz was your typical ASP application. Since throwing away a large code base and starting from scratch is typically a bad idea, the final decision was to have an intern write a compiler to translate a subset of ASP into PHP. Thus, Thistle was born. Thistle had a tokenizer, a simple parser, and a finite state machine based PHP generator. Along with Thistle some work was done to normalize certain parts of the code base to fit the subset of ASP that was allowed. This meant, among other things, replacing all the calls to CreateObject() with Server.CreateObject(), so that those calls could be intercepted and the PHP versions of corresponding objects could be created.

For concepts that just could not be normalized, there was special syntax to embed PHP code directly in the ASP. Thistle has four special comment markers:

  • '#A – This told Thistle that it was entering an ASP only block
  • '#P – This told Thistle that it was entering a PHP only block
  • '#E – This told Thistle that it was exiting an ASP or PHP block
  • '~! – This told thistle that the rest of the line was PHP code

So the following lines would write which language was being used the HTTP response:

Response.Write "This is written in "
Response.Write "ASP"
'~! print("PHP);

It isn't pretty, but the code works properly in ASP unmodified and generates the following PHP:

print("This is written in ");

So with much less effort than rewriting FogBugz, we had both Windows and Unix versions of FogBugz, and Thistle continued to get small updates over the next couple years.

I started at Fog Creek in December of 2005, and my first project was an in-house testing suite. One of the goals of the testing tool was that it be able to give code coverage reports for each test. For this I added the ability to generate ASP to Thistle. The idea of compiling ASP to ASP seems silly, but it was very easy to insert code coverage logging information into the generated code. Once I had code coverage information, I was able to quickly find the areas of FogBugz that were not being tested.

Everyday at Fog Creek we gather around the lunch table and have a great time together. Certain topics and themes come around pretty often. (Such as having a Zoolander themed Halloween party.) One topic in particular kept coming up throughout my first four or five months. No single programming language exists that does all the things that typically require four. You need a server language (In FB5 this was ASP and PHP), a client language (probably JS), a content language (HTML), and a formatting language (CSS).

These conversations and other conversations about features of modern dynamic languages like Python led to the idea of using Thistle to make a new language that overcame many of the issues with writing ASP. There are a lot of problems with ASP, and since Microsoft is no longer making new versions of ASP and doesn't even install it by default anymore, those problems are not going away.

We wanted to make it so that as many programmer errors as possible were found at compile time instead of runtime. This is because it is much easier to be told that a variable doesn't exist immediately instead of having to go through an entire repro-case just to find out that instead of fixing your bug, you have to fix a typo and repeat the test.

So I started writing up specs for proposed features and extensions to the language. After a certain amount of discussion and revision of the initial set of specs I started working on updating Thistle. Thus FogBasic was born, and the compiler was renamed fbc. At first I needed to update the compiler so that it could handle the extra work, so the tokenizer was updated to more fully match the available tokens in the language. I added a parser and generated a full abstract syntax tree. The type checker was the bulk of the work since it needed to be able to infer most of the type information from the code.

Before the type checker was added, I needed to test that the parser and new PHP generator worked properly. So after each compile I would compare the generated code that fbc generated with Thistle's generated code, and once I had them both generating the same code, I was able to start adding type inferencing features.

During the summer of 2006, we realized that I was a complete dork for naming it FogBasic, so we had a naming contest. Everyone submitted their name suggestions, and we did instant run-off voting to decide the name we would actually use. The final two were Bone Crusher 3000 and Wasabi. As much as I wanted to be typing bc3k into the command line, Wasabi won out. Since then Wasabi has continued to get improvements and almost all of the new code in FogBugz 6 uses one or more Wasabi features.

As of today, Wasabi can generate ASP, PHP, and JS. In the future I will talk about how we use these different languages, how we have reduced the amount of code that we need to write, how Wasabi allows us to do meta programming, and how we see Wasabi evolving in the future.