Joel Spolsky has a blog post entitled Wasabi where he writes

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

This sounds like one of those things that sounds like a great way to reduce costs and lower productivity at first until you've had to live with this decision for a few years. There are a couple of other drawbacks to consider that Joel doesn't mention in his post either because they haven't had time to occur yet or probably because FogCreek may be a special case due to Joel's reputation.

  1. Recruiting new employees: Getting four years of experience using Java, C# or even Ruby is one thing. On the other hand, who wants to test what the marketability of "4 years of Wasabi experience" is on their resume?

  2. Programming languages and runtimes evolve: My intern started yesterday and he mentioned that he knows Java but not C#. I gave him a link to C# from a Java developer's perspective which was the most comprehensive comparison of both languages I could find. Since that article was written Java 1.5 has added generics, enumerations, boxing of value types and changed the syntax of the for loop. Similarly C# 2.0 has added generics, nullable types and anonymous methods. By C# 3.0 we'll have lambda expressions, type inferencing of local variables and embedded SQL-like query all built into the language.

    Imagine that you rolled your own language because C# or Java didn't have some of the above features (e.g. closures, lambdas, embedded SQL, etc). At what point do you decide that it makes more sense to keep going with your in-house programming language versus participating in the ecosystem of developer tools that exist around these technologies?

  3. Attrition: What happens when your compiler guru who cut his teeth on a twenty year old textbook on compiler theory decides to leave for greener pastures? Who's going to maintain and update your homegrown programming language as the field of software development evolves and customer requirements change?

These are just some of the problems Joel glosses over as he makes the case for rolling your own programming languages. What may have seemed like a good idea once upon a time often may turn out to be a bad decision in hindsight. Only time will tell, if Wasabi becomes one of those stories or not. 


Friday, September 8, 2006 6:38:52 PM (GMT Daylight Time, UTC+01:00)
I think I am closer to being in Joel's camp in this regard. The latest trend, which is even being promoted by Microsoft, is in development of Domain Specific Languages. I would view Wasabi in this same regard. If Wasabi doesn't have marketability, it is only because the developer writing the resume is not marketing himself correctly. I would happily hire a developer who had experience developing and maintaining a compiler for a DSL. Or a developer who was able to pick up and learn a niche language that did not have mountains of documentation and training support. These are positives in my book not negatives.

I don't know about you, but I have interviewed hundreds of programmers who don't understand generics, boxing, nullable types, anonymous methods etc. A developer who could explain those concepts in the context of why language x was chosen versus language y would be the type of developer I would want to interview further.

Languages come and go. You use the language that meets your needs at the time you need it. I am not interested in what C# will support 5 years from now, if the feature is needed in my program today.
Friday, September 8, 2006 7:02:28 PM (GMT Daylight Time, UTC+01:00)
I guess you meant "reduced cost and increase productivity", not "lower productivity" ...
Friday, September 8, 2006 8:31:16 PM (GMT Daylight Time, UTC+01:00)
I disagree here, Dare. The fact of the matter is that the lines between a library, a framework, a DSL, and a custom language are pretty blurry. To restrict your choices based on what C# or Java might have in a few years is completely impractical. If you need a feature now, use something that supports it.
Friday, September 8, 2006 11:02:36 PM (GMT Daylight Time, UTC+01:00)
Disagree. Isn't Wasabi just Visual Basic with a few differences to enable spitting out php?
Saturday, September 9, 2006 1:25:26 AM (GMT Daylight Time, UTC+01:00)
"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."

Yeah, there's products designed around the concept of supporting multiple platforms and machines that work just fine for everyone else in the world. The best solution certainly isn't to roll your own language.

Joe, they don't have a DSL. The language isn't really domain specific at all, it's just a mutant version of VB.

Maybe if Joel spent less time playing around with trying to invent his own compilers that they don't sell, and more time innovating on the products that they do sell, his company would ship products that might be worth buying. They would capture far more market share by creating better tools than by making sure every cheap ass in the world that is still running NT4 on his 133 Mhz Pentium server can run the latest version of FogBugz.
Saturday, September 9, 2006 2:23:12 AM (GMT Daylight Time, UTC+01:00)
I'm in your camp. You've apparently been around the horn a few times (to quote an old sailors' expression). How many times in my 40+ year career have I seen "It's trivial, I could do it in a weekend" turn into a major multi-month/year effort? I'm one of the two guys who build the only C compiler and runtime for the DEC PDP-11 (RSTS and RSX-11M OSes) based on... the Dragon Book(!!) and the parser generators etc. I still have my copy of the Dragon Book. While this is not the only time I've encountered this syndrome, it's one that sticks out clearly in my memory! -- Bob (Bob Denny)
Saturday, September 9, 2006 4:35:56 AM (GMT Daylight Time, UTC+01:00)
The tendency of rolling your own framework goes beyound Domain-specific languages. I know a company that has a code base that's about 6 years old, and the original designers decided to roll their custom "COM" implementation because real COM programming was too hard and complicated. The result six years later, is a morass of C/C++ code made mostly of checking for pointers, a custom CoCreateInstance, AddRefs and Release, and QueryInterfaces,
Tuesday, September 12, 2006 4:47:28 PM (GMT Daylight Time, UTC+01:00)
"rolling your own programming languages"...but what happens if someone else has to update for example your website? he doesnt know your programming language!
Comments are closed.