Wasabi

I think some people thought I was joking earlier today when I said that we have our own compiler, Wasabi, for FogBugz.

Yes, Wasabi is real. Because FogBugz is sold to customers who run it on their own servers, it has to run on hundreds of thousands of web servers "in the wild," unlike most web apps where the programmer completely controls the deployment environment. We have to ship code that runs out-of-the-box, which means lowest common denominator.

This is kind of unusual. Most web developers are either building things for one customer, or they're building web apps that they will host themselves. That's a nice position to be in. But most FogBugz customers don't want their proprietary project data on someone else's servers, so we have to sell them the source code to install on their own server.

In most deployed servers today, the lowest common denominators are VBScript (on Windows), PHP4, and PHP5 (on Unix). If we try to require anything fancier on the server, we increase our tech support costs dramatically. Even though PHP is available for Windows, it's not preinstalled, and I don't want to pay engineers to help all of our Windows customers install PHP. We could use .NET, but then I'd have to pay engineers to install Mono for all our Unix customers, and the .NET runtime isn't quite ubiquitous on Windows servers.

Since we don't want to program in VBScript or PHP4 or even PHP5 and we certainly don't want to have to port everything to three target platforms, the best solution for us is a custom language that compiles to our target platforms.

Since we are not blub programmers, we like closures, active records, lambdas, embedded SQL a la LINQ, etc. etc. and so those are the kinds of features we put into Wasabi.

And since FogBugz goes back many years and was originally written in VBScript, Wasabi is 100% backwards-compatible with VBScript but includes obvious improvements. """Multiline strings.""" Dim a = 0. And so on.

Most people don't realize that writing a compiler like this is only about 2 months work for one talented person who read the Dragon book. Since the compiler only has one body of code to compile, it is much easier to write. It doesn't have to be a general-purpose compiler. It doesn't have a math library, for example.

And we have the ability to add any feature to the language that we want easily... this is the same power Paul Graham talks about in On Lisp, the power to invent new language features that suit your exact application domain. Lisp does this through a mechanism called macros.

It's very easy to add a new back-end to Wasabi. Our plan is that when .NET gets a little bit more predominant on our clients' Windows servers, we'll add a CLR back-end and generate bytecode or something which will run a lot faster.

Another neat thing is that when you want to do something on the client (the web browser) you can write the code once, in Wasabi, and compile it to JavaScript for the browser and get identically functioning VBScript or PHP code for the server. So for example if you want to do some kind of Ajax-like "preview" feature where a button on the web browser renders some complicated HTML without going back to the server, but you also need the server to be able to render the same complicated HTML in the first place, you don't have to write the rendering code twice in two different languages.

That said, there are major drawbacks. The documentation is a little bit thin and disorganized, because we've only documented the diffs to VBScript, not the whole language. Programmers that join Fog Creek might take a little bit longer getting up to speed. Our edit-compile-test loop got slower because there's one more step.

Should you write your own compiler? Maybe, if you're doing something that's different enough from the mainstream and if there's no good off-the-shelf technology for your problem. There's a good chance that the domain you're working in could really use a domain-specific language. If you want to write a program for filling out tax forms, for example, you probably want to create a language optimized for describing forms with calculated fields, and then all you have to do is encode each tax form in your custom language. If you want to write a program for playing a 3D game, you'll want to create a language optimized for describing maps and levels and then design each level in that language. If there's something off the shelf you can use, by all means, use it, as long as you're not going to get yourself in trouble down the line when you discover that that the off-the-shelf tool doesn't work and you can't modify it.

Students: Fog Creek Software has awesome summer internships in New York City. You get free housing, free lunches, lots of free New York activities, and a chance to write great code with great developers. And a competitive salary. Apply today: we only have four open positions and usually get hundreds of applications, which will be considered on a first-come, first-served basis.

About the Author: I'm your host, Joel Spolsky, a software developer in New York City. Since 2000, I've been writing about software development, management, business, and the Internet on this site. For my day job, I run Fog Creek Software, makers of FogBugz - the smart bug tracking software with the stupid name, and Fog Creek Copilot - the easiest way to provide remote tech support over the Internet, with nothing to install or configure.

Enter your email address to receive a (very occasional) email whenever I write a major new article. You can unsubscribe at any time, of course.