In Defense of Joel's Wasabi Indirection Layer

The point is that wasabi was a stupid idea in the first place. When faces with a situation where you have to deliver your product in two languages on two platforms you don't spend a bunch of time writing a new language and a new compiler. You use a cross platform language.

Surprisingly PHP is just such a language. It runs great on Windows, supports IIS, has full support for SQL server, has tons of database abstraction layers and ORMS, and installs with one click on windows.

It is an idiotic task to write a whole new language when your application is already written in a cross platform language.

I still don't think Joel is that stupid. I honeslty think he is either pulling your leg or doing this to get publicity for his product (which by the way is pretty mediocre).

Thanks for your comments, Joe. I appreciate the input, and you have hit on exactly the part of the debate I find interesting. I cannot agree, though, that I missed the point entirely, or that "wasabi was a stupid idea in the first place."

In my analysis, this all comes down to two determining factors: first, did Fog Creek implement a solution that made sense within their business situation and given their specific goals; and second, does the thing work?

From reading everything Joel has written on the topic, and taking into account my general high regard for what Joel has to say (a regard that is clearly not shared by all), my conclusion is that an "indirection" language with target-specific compilers seems like a good idea given Fog Creek's market realities, business goals, and legacy code base. In his "Wasabi" post, Joel addresses the PHP question raised by Joe:

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.

One can disagree with his reasoning, but its clear that it's not like they just failed to account for PHP's cross-platform support. Joe, you also write that "It is an idiotic task to write a whole new language when your application is already written in a cross platform language." I think this misses two critical points:

First, as Joel himself explains, they started out with a legacy code base (VBScript/ASP) that "goes back many years." So a full port to PHP would be in order; even if you can pull that off quickly, you run smack dab into the second critical point: PHP may be cross-platform, but there is resistance in Windows-oriented development shops for adopting a PHP application for something as critical and long-lasting as a bug tracking and task management system.

I have witnessed exactly this resistance myself in two different shops: certain managers (whether your or I think they were right or not) refused to consider a PHP application to run on their IIS servers. We could debate about whether this is logical, and bitch about how stubbornly homogenous Windows adopters can be, but when you're trying to maximize your potential customer base and give people what they want, the calculus is different.

Which brings us back to what I identified as the second determining factor: does Wasabi work as advertised? Can you really write the application in Wasabi, run it through some compilers, and come out with a sound, secure, and performant PHP5 application? I personally have no idea, and I can think of several things that would make that tricky, but at this point I'm willing to give Joel and Fog Creek the benefit of the doubt that it does work--otherwise, I don't think they'd be using it, and I don't think they'd be bragging about it. But I could be wrong.

Thanks again,
Dan

Joe, you (and DHH and his swarm of followers blinded by rage over the criticism of RoR) are the one who completely misses the point. As Joel already explained in his follow-up post:

"Even though PHP is available for Windows, it's not preinstalled"

There are big differences between writing internal or hosted apps and writing packaged software. The minute Joel picks PHP as his implementation language of choice, he's instantly going to be cutting his revenue potential in half. As Daniel pointed out above, just because PHP will run on IIS doesn't mean companies are going to install it.

Out of the companies that I've worked for, most probably would not be willing to install PHP in order to run a bug tracking system if they had a choice of another system that would run on plain vanilla IIS. Thus the obvious solution that DHH-and-company can't see even when it's spelled out to them.

After reading your "I don't recall Joel at any point saying that Wasabi included embedded SQL...." I double-checked and
"...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." at http://www.joelonsoftware.com/items/2006/09/01b.html

Good post!

Cheers,
Larry

Hey Dan,

No, you can't write in one language and expect it to output a sound, secure and performant PHP 4/5 and ASP application, unless you target the lowest common denominator between N enviroments, otherwise we would have already the one true language, which outputs to 2 languages, which in turn output to 4 languages, and it goes on and on until machine code is reached.

But if you target the lowest common denominator, or you have a sales pitch like Joel's "you get the source code to fix any bugs" (which is awesome IMHO), Wasabi is a good thing. FogBuzz probably doesn't scale to Wikipedia or LiveJournal's level without some *heavy* modifications, but who cares? It won't probably ever need to.

I am not making less of Wasabi for targetting what I called the "lowest common denominator", what I mean is that I think there isn't a need for the more advanced stuff from each language (PHP or ASP), and anyway, different files can be written on each language and later included on the distribution to complement a feature after Wasabi is "compiled".

And I don't think you quite understand what Copilot is... the part "hosted" is pratically nothing, since the product is mostly a VPN with a central proxy (hence the C#). RoR, or any other web framework, would have solved very little to its development problems.

I do not want to go into the depth of the last comments, nor do I have the time for it (here in Israel, it's not that rare for developers to work 12-13 hours a day).

What I'd love to say is that, as Joel wrote, people tend to be too protective of their Programming Language of Choice. The Ruby guys were "insulted" and were in too hurry to insult the VBScript language. I do not think that either is bad, but it's all a matter of the right place to use each one. If not for VB, VBA and their relatives, a lot of self trained coders would have probably won't have the break to start their careers. I, personally know of some small products, which are VERY productive and cost effective to their clients, that are written in uncool languages, such as VBA over MSACCESS. The client doesn't give a (beep) about the architecture, the designability, scalability of other buzzility of the product. He wants it fast, good, and cheap. Sometimes the best thing (from the business point of view) is to do just that.

And here enters my second argument, the one that's stated in the comments title. You are not always in the need of the full armada of soldiers to get yourself a little hilltop. Not need the wall Auto-Bots in order to take out the whiny Star-Scream. Even Bumblebee would do.

Therefore, choosing the well-aimed-for-it's-target Wasabi for the exact situation were needed, was probably a good decision, without the debate of if it's a good or bad language.

Is French a bad language? It depends on the where you live. Maybe English is better, but both wont do you much if your living underwater. (okay, that was a long shot. cut me a break - I need some sleep to be coherent).

So g'dnight.

This is a very interesting discussion. As Ken points out, people do indeed tend to be protective of their programming language of choice. In addition, programmers also tend to be disdainful of programming languages that they choose not to use or that they know little about, a point I have made myself once or twice.

Joel's choice to write an app in a propriatary language to solve an adoption problem among his user base (whether it's Windows users refusing to adopt a PHP program or Linux/Unix users refusing to adopt an ASP program) is interesting and was clearly his call to make. My take on Joel, from reading many an interesting post to his site, is that he likes to do what he likes to do. He makes "shrinkwrapped" software because that's more fun than writing custom business software. And he happens to be at a place in life where he's free to make these kinds of choices.

Still, going so far as writing an application in a propriatary language is clearly a big leap, and not something I think would work in most situations. Edward Nilges often speaks of how developers get in trouble for reinventing the wheel--creating new tools where 3rd party tools exist, for example. Sometimes it makes more sense to re-invent the wheel than to figure out how someone else's wheel is supposed to work and how it's supposed to integrate with your monster truck.

Personally, though, I think using your own language is a bridge too far when there are so many languages out there. It's not just that your language might not be perfect or mature. To me the real problem is that widely accepted languages have tons of tools and toolsets available to improve your productivity. If you've rolled your own language, well, you're own your own.

Did the Fog Creek team write their own IDE, I wonder? Write all of their own string parsers, etc? Clearly they seem to be happy with this situation, but I can't imagine that it's applicable to a lot of other business problems.

Also, I wonder why they did not choose to write their app in one language or the other and then write a translator that would translate from VBScript, say, to PHP? Obviously you'd be stuck with a lowest common denominator subset of the language you used to make sure everything would translate, but this seems like a much more productive and easier to maintain/test situation than using your own langauge.

Regardless, I bet it was a fun project to work on!

I'm not entirely sure about Joel's technical choices (C, C++ or Perl might have been better), but I've certainly learned that it is important to have control over as much of the product code as possible. The often overused phrase about not re-inventing the wheel is more applicable to smaller in-house development projects than it is to major commercial endeavors. You can’t fix what you don’t own – and you always need to fix problems with software.

As far as products are concerned, any specific language issues should be mitigated by packaging. If the product installs easily and cleanly, and doesn’t require significant external maintenance, then the language and underlying technologies used to build the code becomes insignificant. Integration with other products should be isolated from the main development stream – so again the language used to develop the core should be encapsulated. Suitability, stability and the ability to hire experienced programmers are probably more important issues.

So far, most of the discussion has centred on the relative technical merits of one choice or another with the odd side-track into packaging and deployment considerations. I'd like to offer my perspective as one of the 3 people charged with keeping everything up and running.

For better or worse, it has become my role here at Crestline to make sure that risk assessment is given at least lip-service. I am of the opinion that every new install carries with it some risk of system instability. Likewise, every new server also introduces risks. It's true that the risks of not installing something or adding a server are greater than those associated with the potential for instability, so that is where the analysis comes in.

In the vast majority of cases, there is a good-enough solution available that limits the impact on our existing system. If we are a Linux shop and FogBugz runs only on ASP, then I have to help decide whether to find a way to get ASP extensions in place, add a server, or find something 'native' that will be good enough. Similar concerns apply if we are a Windows shop already running IIS with FogBugz available only in PHP.

In both cases, even if FogBugz ships with a one-click install, full uninstall/rollback capabilities, free (and fast!) install support, and a money-back guarantee, I will be checking to see what additions and changes to our system are really there. If I feel that the changes amount to the implementation of a whole new operational platform instead of a 'simple' application that utilizes the existing platform, then I start looking for alternatives. In the case of FogBugz, I'm quite certain that suitable alternatives can be had without requiring that I install a whole new platform, regardless of how easy that install might be.

I'm not sure that Wasabi was the optimal solution, but I think the concepts are quite sound. Although they still have two code-bases to maintain (Wasabi and Fogbugz instead of FB-PHP and FB-ASP), they make it very hard for me to find reasons to not buy.

Any idea on how the Fog Creek folks will reuse that platform (PHP and VBScript) libraries? A lowest common denominator may be the case, but then I think this denominator is very minimal (e.g. even basic classes have different methods in different languagues). Hmm...