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