Chad Perrin: SOB

13 September 2006

Happy Programmer's Day!

Filed under: Geek — apotheon @ 05:51

The 256th day of the year is Programmer's Day. Have a good one.

a quick response to Joel's most recent folly

Filed under: Geek — apotheon @ 05:30

Yesterday, Joel Spolsky posted a continuing defense of his anti-Ruby rant, Language Wars. This new bit of linguistic anti-advocacy is called Ruby Performance Revisited. My initial knee-jerk reactions follow:

  • He doesn't understand duck typing very damned well.
  • His performance figures are ridiculous.
  • He still seems incapable of understanding that it's sometimes a good idea to use libraries written in a language other than the core project language.
  • He sure is hung up on benchmarks.
  • He backpedals very quickly in the last paragraph on his original suggestion that Ruby is almost universally unsuitable for production development, though he does so in an understated manner as if this new pronouncement is what he has been saying all along.

More about "outsourcing" your performance-intensive functionality can be found at David Heinemeier Hansson's Outsourcing the performance-intensive functions, which I stumbled across after composing the above list of reactions to Joel's commentary. DHH, in case you are not aware, is the creator of Rails (as well as being a new TLA).

Wasabi: more heat than light

Filed under: Geek — apotheon @ 05:14

Today, whilst discussing what title I was going to give this entry, Sterling offered the following observation:

You know that intense feeling you get when you eat too much wasabi? Someone I once knew called that brain damage.
Considering all the mental flailing about that has been going on over the subject of Joel Spolsky's in-house development language Wasabi, that seems strangely appropriate.

I have been watching this whole Joel Spolsky Language Wars fiasco unfold since Day One. I have been a part of the discussion in mashup communities like reddit, mailing lists (such as ruby-talk, bidirectionally gatewayed with comp.lang.ruby), and weblogs. I have seen, and tended to agree with, many of the criticisms of Joel's commentary. Here, I enumerate a few of the more obvious examples:

  • Wasabi is supposedly based on VBScript, which seems to directly contradict all the good stuff Joel has said about it.
  • Everything Wasabi purportedly provides already exists in other languages — languages that are more mature, and aren't based on VBScript.
  • The announcement of Wasabi's existence followed a lengthy screed about the unsuitability of languages and tools other than Java, .NET, PHP, and maybe Python on a good day, for web development, thus making him a hypocrite at best.
  • Not only do very few people know this language (a complaint he uses against Ruby in the same essay), but nobody knows it if they don't work for him for a while and learn it from him and his employees.
  • A language with such a tiny maintainer community (all three of its users) will be prone to unexpected bugs and, judging by some of the discussion I've seen, this manifests as some awful bugginess in Joel's FogBugz bug-tracking software (ironically).
  • His justifications for Wasabi effectively defuse all his arguments against other languages not as "proven" as Java and C#. Why even mention it at the tail end of that essay?
  • As Damien Katz points out, DSLs are a great way to abstract away some of the work of a project, but Wasabi can't reasonably be a DSL so much as a general-purpose language with domain-specific kludges layered on.
  • Compilation/interpretation speed for Wasabi has got to be atrocious at best.

    There are people who have complained at length about these shortcomings and others. Damien Katz wrote Has Joel Spolsky Jumped the Shark? (also linked above). Jeff Atwood wrote Has Joel Spolsky Jumped the Shark? (yes, the same title, right down to the capitalization, but no, not the same essay). Oddly, though the biggest problem with the Language Wars essay is the inherent contradictions and bizarre daycoder, pointy-haired boss tone of Joel's arguments, people are mostly focusing on the notion that Wasabi is a tremendously bad idea. In their zeal to discredit Joel's technical decisions, they are often getting the analysis wrong on some key points (though not all of them are doing so, of course).

    Here's what I've figured out about Wasabi, with some commentary:

    1. It is, in Joel's words, a "very advanced, functional-programming dialect of Basic with closures and lambdas and Rails-like active records". If you ignore the "dialect of Basic" part, it sounds suspiciously like he could have just used Scheme and written a small library for active record handling.
    2. Also in Joel's words, it "can be compiled down to VBScript, JavaScript, PHP4 or PHP5." A common complaint about the Wasabi idea is that it must be very, very slow in production environments, and speed of the interpreter or compiled code is one of the points Joel harps on when declaring Ruby unfit for scalable web development. What these critics miss is that Wasabi is compiled to other languages in the shop, and the code in those other languages is then shipped with the FogBubz software, as I understand it — which renders the execution speed concerns about Wasabi moot in production environments.
    3. More of Joel's words: "Wasabi is a private, in-house language written by one of our best developers". Everybody seems to think this is insane, but really, it seems somewhat reasonable. The problem that arises is that what he describes isn't a very limited DSL. It's a syntactically distinct superset of VBScript, which is just . . . nuts.
    4. The compiler for Wasabi is written in C#. This, unfortunately, means that it is entirely possible that Wasabi might be shipped with the product — but, even if it is, at least it's likely to be easier to install than a Rails app.
    5. The language is probably almost useless for anything other than writing FogBugz, thanks to the fact that it was written specifically for that purpose and is continually optimized to that end using whatever buzzword-compliant technology rules the day at Fog Creek (Joel's company). Joel seems to think this makes it a domain specific language, but it doesn't. It makes it a crippled general-purpose language.
    6. It has no math library, natch.
    7. It is effectively closed-source and proprietary, and nobody outside of Fog Creek and its clients can use it — as if they'd want to, considering its limited usability.
    8. They're planning to make it compile to CLR code, too. This is an excellent idea, if they're going to continue using Wasabi, except that it strikes me as mental masturbation considering the very limited range of uses for the language. I just can't get over such a limited-use general-purpose development language design.
    9. It is 100% backward-compatible with legacy VBScript code. This is the only thing I've seen that even begins to justify building it on VBScript, but it seems to indicate to me that there's something desperately wrong with the upgrade and development process as well as the modularity of code that they need to make it backward-compatible with VBScript. Maybe I'm mistaken in that.

    The major win for Wasabi seems to be that it is a unified development language that is used to write code that will ultimately become executable scripts in any of several different other languages without having to write another line of code once the Wasabi is written. The difficulties appear to arise in figuring out how the hell you can get closures, lambdas, and functional syntax to compile to VBScript, Javascript, and PHP on command, particularly without hamstringing your language design to the point where it would be painful to use. You'd probably have much better luck just writing a cross-language compiler between the three, and let your programmers use whichever of the three they prefer. In cases where you prefer client-executed Javascript with a server-executed back-end as a fallback in case the browser isn't going to execute your code, though, this is not a poorly conceived approach to solving your duplication of effort problems.

    This entry at SOB isn't meant to draw any final conclusions. That's up to you (or me, if I post on the subject again, perhaps). It does draw some intermediate conclusions, but I have a hard time imagining those conclusions being avoided by any kind of reasonable analysis. It's just a paint-by-number of the Wasabi landscape, as viewed from where I'm sitting.

Older Posts »

All original content Copyright Chad Perrin: Distributed under the terms of the Open Works License