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.
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.
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.