[A picture of private offices at Fog Creek Software] Alert! This ancient trifle retrieved from the Joel on Software archive is well-past its expiration date. Proceed with care.

Joel on Software

Wasabi

by Joel Spolsky
Friday, September 01, 2006

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.


Have you been wondering about Distributed Version Control? It has been a huge productivity boon for us, so I wrote Hg Init, a Mercurial tutorial—check it out!

Want to know more?

You’re reading Joel on Software, stuffed with years and years of completely raving mad articles about software development, managing software teams, designing user interfaces, running successful software companies, and rubber duckies.



About the author.

I’m Joel Spolsky, co-founder of Fog Creek Software, a New York company that proves that you can treat programmers well and still be highly profitable. Programmers get private offices, free lunch, and work 40 hours a week. Customers only pay for software if they’re delighted. We make Trello, which lets you organize anything, together, FogBugz, enlightened issue tracking software for bug tracking, and Kiln, which provides distributed version control and code reviews. I’m also the co-founder and CEO of Stack Exchange. More about me.

© 2000-2014 Joel Spolsky