Coding Horror: Has Joel Spolsky Jumped the Shark?

September 11, 2006

When you're starting out as a technical blogger, you'll inevitably stumble across Joel on Software. He's been blogging since the year 2000, when computers were hand-carved of wood and the internet transmitted data via carrier pigeon. He has his own software development company, a few books under his belt, and he's an outstanding and entertaining writer by any measure. In many ways, Joel is a legend.

Although Joel's blog entries are generally pure gold, he has generated his fair share of controversy in the last six years. For example, he doesn't like programming using exceptions, despite the fact that they are the bread and butter of modern programming languages. He also said that teaching new programmers only Java is liable to poison their minds, although I think Java is the least of any budding new programmer's problems. But a few of Joel's recent posts go far, far beyond these minor gaffes.

For instance, two weeks ago we found out that Joel's company wrote their flagship product, FogBugz, in a proprietary language they created themselves.

You couldn't possibly have heard it, but that was the sound of fifty thousand programmers' heads simultaneously exploding.

Writing your own language is absolutely beyond the pale. It's a toxic decision that is so completely at odds with Joel's previous excellent and sane advice on software development that people literally thought he was joking. He had to write an entire follow-up post to explain that, no, he wasn't kidding.

Read his defense of Wasabi. If anything, it amplifies the insanity. Because, you know, installing a PHP/NET/Java runtime at a customer site is totally unsupportable, even though it's the business model of 99.9% of the rest of the world. And with Wasabi, they can add any language features they want! Just like Lisp, right? And eventually they'll plug in a .NET CLR back-end to Wasabi and generate bytecode! Never mind the fact that your company's flagship application is still written in a freaky custom language based on VBScript that only three people in the world know how to program.

But wait! It gets worse!

Now Joel says that a dynamically typed language like Ruby can't possibly be fast enough to run FogBugz:

Let me get this straight. Let me make sure I'm understanding this. Because I think I've gone crosseyed.

All of this makes me wonder: has Joel Spolsky jumped the shark?

I reject this new, highly illogical Joel Spolsky. I demand the immediate return of the sage, sane, wise Joel Spolsky of years past. But maybe it's like wishing for a long-running television show to return to its previous glories.

Posted by Jeff Atwood

Somehow, i suspect this latest series of posts is just an internal Fog Creek argument bubbling to the surface.
Which doesn't make it any less sad, but i think gives a little more understanding of the Ruby-hating: Joel doesn't want The World At Large to not use Ruby, he wants his own team to do so...

And speaking of poisoning programmers... VBS?

What, you mean the guy who thought web applications had no future?

I've never been impressed with Joel's technical acumen. He's a great writer, and good at understanding and explaining the people side of software. But the technical side...not so much.

It is a sad thing to say, but I think he did. You have a good point about writing performance sensative parts in compiled language. In this case people use extensions written in C. "duck-typed function call", huh?

At the risk of being rude, Joel is a pompous ass and hasn't said anything interesting for years. He's now also plainly gone completely insane, and the poor old dear should be taken out and shot...

From the look of things, VBScript (and weird VBScript derivatives which compile to PHP) have a far greater mind altering effect than Java.

1. Wasabi: it does seem a little much to develop your own compiler for a single web application. BUT, presuming he has plans for future web projects using this same homegrown language, this strategy begins to make sense. Shrinkrwap for the web? Think about it.

So wait two years and check back and see if anything turns up.

2. Classic ASP performance - you've made the assumption that all their heavy calculations run inside the ASP page*. I'll make the equally-plausible assumption that they aren't running any heavy calculations in VBScript. Who's right?

*I know what the P in ASP means, sorry for any pain I've caused you

I think for some subjective reasons, he doesn't like Ruby and he's grasping at objective straws to put it down.

Poor Joel, what a sad end for a beautiful mind... :)

Anyway, he MAY be right with Ruby's slowness (I've always suspected that Ruby may be... inappropriate for heavy-duty business apps), but WHY, for the sake of effing baby jesus, would you choose to develop your own pet language.

And it's based on one of the worst pieces of CRAP in the programming world...

But wait...

Oh, I get it! It has a cool name: Wasabi!!! Thake that, Matz!

Jeez.

What killed me was this:
"In FogBugz 6 there's one place where we need to do literally millions of calculations to display a single chart on a single web page..."
Assuming that by "calculations" he means "discrete logical steps" (as opposed to assembly instructions) that has to be one of the dumbest things I've heard. It begs the question: WHY? Why does it take "literally millions" of steps to display a single chart on a single page? It's a BUG TRACKER. What could it possibly be doing? Why is it so complicated?

"BUT, presuming he has plans for future web projects using this same homegrown language, this strategy begins to make sense."

FogBugz is at least four years old. The only other thing to come out of FogCreek was written by interns over one summer. How much longer do we have to wait?

Hmm, the more I read the latest Spolsky, the more I feel like firing on the Red Cross.

"In C/C++/Java style languages one way you can handle errors is to use the real return value for a result status, and if you have anything you want to return, use an OUT parameter to do that. This has the unfortunate side effect of making it impossible to nest function calls, so result = f(g(x)) must become:

T tmp;
if (ERROR == g(x, tmp))
errorhandling;
if (ERROR == f(tmp, result))
errorhandling;

This is ugly and annoying but it's better than getting magic unexpected gotos sprinkled throughout your code at unpredictable places."

-----

Please, Joel, PLEASE. How in the world could the above CRAP be better than a robust try-catch-finally (speaking c#, here) implementation? And what about NESTED exceptions? Will you add another "out" parameter to deal with that, or some other ...hoopla?

Ewww.

Amen brother. It's good to hear a refreshing "no sh**" response.

Joel's koolaid is way too sweet.

"[...]writing performance sensative parts in compiled language. In this case people use extensions written in C. "duck-typed function call", huh?"

That expression doesn't means duck tape, and it isn't derogatory, it relates to dynamic typing http://en.wikipedia.org/wiki/Duck_typing

The guy is certifiably loony. The past few weeks of posts could be headlines on TheDailyWTF.com.

I feel more sorry for his developers who has to explain why they don't know PHP / ASP.NET / Java / Ruby, etc. at their next interview.

I want to defend Joel. He is running a business, making money, and treating his employees the way that we want to be treated. He has the freedom to choose whatever environment that makes sense for his business.

Sometimes what makes sense for business does not make sense to the new tech hyped geek. The death of COBOL has been proclaimed for over 20 years now, but it is still going because it makes business sense. My company is currently coding in Assembler, COBOL, VBScript, C++, VB, VB.NET, and C#. Many times an older technology is a better business decision. While most alpha geeks would not be caught dead coding in COBOL, I have code that I wrote in 1990 running today with little modification in the past 16 years.

In the end, a professional application programmer has to create a product that meets business requirements, even if it is not in the hippest new language or environment.

Take note: You refute very little of what he said, instead just calling him nuts.

I don't agree with Wasabi but I see where he's coming from. He's making it as easy as possible to use FogBugz. Doesn't matter what kind of setup you have, he has a FogBugz for it. That does give you a slight edge over everyone else.

By reducing performance needs he, again, has access to a larger possible install base. Not every company upgrades their servers every 6 months.

He made his trade-offs, he's living with them, and, more importantly, continuing to succeed.

I think you guys are coming off pretty dickish. I hope Joel keeps writing high-quality blog posts because I still like to read them.

He's been wrong before, and he'll be wrong again. A fool never changes his mind, but a wise man does so regularily.

Whats great about this Ruby debate is that it's at least resulting in developers making *informed* choices, rather than blindly following 37 Signals down a path without considering it carefully. At least programmers are learning what trade offs they are making when they choose Rails (or any web framework for that matter).

As for Wasabi, who really gives a shit. It's about as interesting to me, as knowing what coffee machine they use in FogCreek. I am pretty sure it works, and I am pretty sure it's just an abstraction of a version of fogbugz, once they realised they were doing the same thing over and over.

Similar to what 37Signals did with Rails, except not public or free, not known about, and written to use retardo languages.

I'll still continue to read his stuff, even when he is wrong he is entertaining, and half the fun sometimes is in coming up with counter arguments in my head. As for Jumping the Shark, either side of this Ruby stuff he had written 3 great management articles, and an impressive guide on people management (recruitment etc), so the quality is there, just ignore the posts that could be perceived as flamebait.

A lot of people including myself agree with his stance on exception handling.

There are many arguments on the subjects.

But the first point that needs to first be understood by all that there are EXCEPTIONS, i.e. stuff that should never happen, vs and that return value that indicate a 'failure' or an action not taken because of some reason that is totally reasonable and perhaps even frequent.

newbies are taugh to band return codes and use exception for everything, which is bad.

You do not know in what state the objects are with exceptions, have they done their proper cleanup? Were there in the middle of something? Was it an exception they got from a sub-object that they couldn't handle? The complexity increases because it's very hard to write GOOD exception-based code.
Also any change to that code can mean the exception handling will be different; you've lost the knowledge of exactly when the error occured.

All the examples above given are bogus, they only show how the calling code is 'cleaner'.

Well these examples are not handling anything!

The exception may have more information in them, you have to write code to properly use that information!

You also have to structure your code in object in order to insure proper construction/cleanup.

These examples are strawman arguments written
like old C code, which isn't viable in a non-trivial system. They do not demonstrate anything.

I've been a reader of Joel's for years. And the reference to Wasabi bugged me for a different reason. He just finished a post on why his friend should not use any language for new development that had not been tested sufficiently in the field. He specifically said his friend should use asp or java over ruby because the latter hadn't been battle tested. And then he brags about a language developed in-house. Gak!

@QuietGeek

I think it boils down to this: it's fair enough to point out that Ruby is slow. This is true, verifiable, and part of consensus reality. The Ruby community is aware of this fact, and has long-term plans towards fixing this.

It's quite another thing to talk about how you can't write fast applications because dynamically-typed languages require a bunch of hash-table object-method hoo-ha, when your own flagship product (which is written in some kind of moonshine VBScript, natch) is compiled into PHP, *a dynamically-typed language*.

*head asplode*

Joel seems like a nice guy, so I guess our best hope at this point is to sit tight until his friends and family stage an intervention.

Wasabi sounds like the language/environment that I've been walking around in my mind with for a few months now.

I would develop it if I had the time and necessary brilliance.

So yeah, I was pretty excited to read about it, and pretty sad only so little was said. I didn't regard the performance though, and I don't much care about it. I want my developer time to go down while performing such repetitive tasks as writing web applications (dozens of similar-yet-different CRUD operations and access checks tend to dumb you down quite a bit).

In the end, a professional application programmer has to create a product that meets business requirements, even if it is not in the hippest new language or environment.

I agree with you, and I reluctantly agreed with Joel when he said he wasn't in a rush to upgrade FogBugz to ASP.NET (in 2002) just because it was the Next Big Thing from Microsoft:

http://www.joelonsoftware.com/articles/Our.NetStrategy.html

I'm with you. I really am.

However, *instead* of upgrading to ASP.NET, they decided to.. write their own proprietary language that compiles down to VBScript/PHP/JavaScript.

I just can't get behind that. It's a one-way ticket to crazytown. When was the last time you encountered a problem and thought to yourself, "Mmm. What I really need here is MY VERY OWN PROGRAMMING LANGUAGE."

That said, of course it's Joel's business and he can do whatever the hell he wants. But part of his whole schtick was believing the man behind the curtain was following the same good advice he's been giving people.

Clearly that isn't the case.

Like most of you, I've found Joel's recent posts a bit off track, but I think all this discussion about Wasabi, VBS, etc. just demonstrates an important point about the software business: most of the time, the technical details don't matter.

They matter to *us* - those of us actually doing the development, but not to the customer. FogBugz is a pretty successful product because Joel listens to his customers and follows good business and management practices. I think had he chosen any other reasonable set of technologies, it would still be a success.

So while I think VBS sucks, and writing your own web development language is a bad idea, I still think Joel knows a lot more than me about creating a successful business and *that's* why I read his stuff.

Notice all the posts on his new job board? And all this "controversy" over his recent posts certainly isn't going to hurt that new business.

I'm shocked. Shocked I tell you! After years of reading Joels' advice on good coding and how to interview and all of his other writings; I can't believe that he has based his sofware on a homemade programming language that is similar to vb. VB Sucks!! SUCKS!! And who in their right mind creates a programming language? It kind of makes sense why we don't see massive installs of FogBuz all over the planet.
Christ I told 3 people about Joelonsoftware.com today and a few last week as well. Now I want to track them all down and tell them that I'm am sorry for giving them bad advice.

So Joel has written his own programming language so he can automagically generate FogBugz code that runs in ASP/PHP/ASP.NET, depending on which environment the client prefers? What a "bad" business decision!

I know, I know. He should have written everything in RoR and all his problems would have been solved.

Who's been drinking the KoolAid, guys?

I can relate. I've long admired Joel - he is a *fine* writer; I have even laughed out loud at his posts. And when he's in form, he obviously knows some very smart things about programming. Then he pulls a Wasabi or waxes poetic on Bill Gates' programming abilities or sticks up for Visual Basic... retch!

This is what happens when you drink too much Kool-Aid, kiddies, even if you're really smart. Look and learn.

I have enjoyed some of his writings (perhaps the older ones?). Tried out his software but didn't buy it. The interns seemed to come up with a good product (what were the full-timers doing?), and for that credit must at least in part go to the interview process and working environment.

He spends a lot of time writing eloquently, but he may indeed have lost touch with certain realities.

While I'm at it, every one you readers that do not program Win32 apps in Delphi, at least in private, have jumped the shark already, as has anyone who by choice uses a case-sensitive language, or, who thinks AJAX is ready for prime time.

I can't help but think a lot of this controversy is people who see "WROTE THEIR OWN LANGUAGE" and think Wasabi is this thing they spent thirty-thousand man-years on and is ready at any moment to shake free of the confines of Fog Creek and brutally compete with, say, PHP.

Rather than a project that I'd wager has got less than two man-years into it, admittedly two of their more valuable man-years by one of their better programmers, but probably by now, more than paid for itself.

Has no one taken a compilers class in the past 20 years? Writing a language that is described as "very VB-like" that "compiles" down to VB and PHP isn't something I'd throw a high-school student at, but we're not talking brain surgery here either! VB and PHP still do all the *really* hard parts of that problem.

Anybody who's passed a compilers class ought to be able to write the basic shell of that *well* inside of a month from scratch with appropriate tools, less if you can find a convenient VB-like grammar already written for you, and from there, you're off to the races incrementally implementing features over VB. The PHP backend would be harder, but since you've got control over the PHP you emit even that shouldn't be *that* hard. (Taking in arbitrary PHP and trying to convert back to Wasabi, now *that* could be hard.)

How hard do all of you think this is?

Ervin: A perceived lack of portability is not a good reason to write your own damn programming language. Joel has written himself a Turing tar-pit (http://weblog.raganwald.com/2004/10/beware-of-turing-tar-pit.html).

But hey, it's not like portability or "write-once, run-anywhere" technology has really been explored in depth, right? It's a marvelous new frontier, and VBScript is the perfect starting point for such a bold exploration of the technology... of the fuuuuuture!

This is not surprising at all. If you take a look at the game industry most of them have their own scripting languages to drive the main game engine. Some of them are based of other languages, like Lua a super small scripting system or python but others are created by hand. Companies like Garagegames.com, IDSoftware and Unreal who have crafted their own or taken from an existing one and crafted it into something they needed. The concept of creating a mini or simple language to drive your core application or to generate code to compile or run on a larger system is not a new concept. It does make people worry about how to support PHP, VBscript and JavaScript but one would hope that you would only have to work in Wasabi to make the product meet your needs.

Yes. I think I, Cringley had his day, and now sadly Joel's sun is starting to set. I think you are right, at one time, his blog was something of a touch-stone, but now again, sadly, the world has caught up to him and waved to him as we sped by. And what we see in the rear view mirror is simply nostaliga.

Goodbye Joel.

I don't think they really wrote their own language as stated there.

It sounds more like a code generator/converter.

In other words, they wrote a YACC which is used to convert the code to another, existing language. One VBScript line could generate five line of PHP.

This is no different than using macros or a class library in C++ in order to have the code automagically written.

And there is nothing fundamentally wrong with it. sequence of high-level operations.

It allows one team to code with a small, controlled language, and another team, the porting team, to 'map' that language to the various architecture and langages. They do this by modifying the so-called 'compiler'.

Coda: I tend to agree with ulric.

From a business point of view, I think it was a very good decision.

Actually, regardless of what you think of Wasabi or Joel, this is at least a pertinent innovation which suits his own purpose.

Just because its not innovation of a general purpose language or integrated with the rest of the world in an easily consumable way doesnt matter. He is free to experiment and is doing so to a much greater extent than many shops.

One of my laments about Java is not the language but the way the Java community has failed to provide useful supersets of Java functionality which truly aid application development.

How can you whine about Java APIs and then never wrap them behind something far superior?

Apache has tried on some level but their level isnt necessarily going to be right for everyone.
Tool vendors have tried and theres some good stuff but the language is going the way of the dodo.

Anyway I think its easy to assail someone who goes there own way but it shows a bit of cargo cult mentality which is why Ruby is ahead of Java on some fronts, because Java programmers stopped thinking altogether and just did struts until someone mentioned that struts isnt cool anymore and maybe never was that cool.

Since when did anyone need permission to write their own programming language anyway?

"Some of them are based of other languages, like Lua a super small scripting system or python but others are created by hand. Companies like Garagegames.com, IDSoftware and Unreal who have crafted their own or taken from an existing one and crafted it into something they needed."

id Software and Epic Games (the company behind the Unreal engine) started working on their products long before Lua, Python, etc. became serious alternatives to creating your own scripting language from scratch. UnrealScript in particular goes back to 1998. Had things been different, I strongly suspect that those companies would have leveraged existing languages.

Repeat after me: "Joel Spolsky is the new John C. Dvorak".

I dont think Wasabi is as fully fledged a language as Joel would like us to believe. I seem to remember him writing about creating a tool to generate php apps from their existing asp codebase when he decide to support unix servers. At the time it was decribed as a fairly simple system that took advantage of the polish notation they used in their codebase to do a good job of spitting out a php app from their codebase, and only their codebase (not a generic asp-php compiler). I reckon wasabi is that tool, and at some point they wacked a precompiler onto it and now it generates both asp and php from the souped up asp files. This is all just a guess, but I reckon any competant asp programmer would probably recognise 90% of the code in wasabi, and could figure out the quirks by looking at the wasabi source, and then the generated asp source. So a new hire probably would not have quite the uphill struggle you imagine.

"id Software and Epic Games (the company behind the Unreal engine) started working on their products long before Lua, Python, etc. became serious alternatives to creating your own scripting language from scratch. UnrealScript in particular goes back to 1998."

What? Do you realize that Python is older than Java? By 1998 Python was quite mature. In 1998 Google was using Python for its web crawler, Zope was making an impact and the seventh international Python conference was happening.

The reason Python wasn't used back then was partly for speed considerations. Games were CPU limited and memory was scarce. Python may seem like it has a small footprint now, but it wasn't that small back then...especially in games.

That said, I think Lua is a better choice for game scripting. These days "scripting language" is sort of a misnomer as far as Python is concerned IMHO (despite its roots as one).

joel can do or say anything he wants. im no more impressed by any of your comments than his.

also, it would be great if some of the folks who 'know better' could post links to all the kick-ass software they've written so we can all check it out. not that we would notice their mad skills anyway.

its about the application, and how well it works and solves the problem. your genius code can be rewritten or scraped at any time by the next guy. writing a bug tracker doesnt seem like the greatest contribution of the 21st century anyway, i dont know what you expect from him.

Your argument against Wasabi seems to boil down to the fact that it's "beyond the pale," "insane," etc. These don't sound like actual arguments to me; they're just assertions.

FogBugz is a shrinkwrapped web app installed on customer's own servers. It was originally written in VBScript way back when that wasn't the worst idea in the world. Given our business constraints, spending two months writing a compiler that could preserve our code base, improve the language we used day-to-day, and continue to produce source code for our customers that runs on their platforms was the best business decision, even if it might make your head explode. Even if, as you claim, installing a PHP/.NET/Java Runtime at a customer site is everyone else's business model, that doesn't help us because our code is in VBScript and has been for many many years. We could port the VBScript to PHP/.NET/Java by hand, or we could spend two months writing a compiler. The latter decision took less work (a couple of months) and produced better working code that runs on all our customers' machines without modification. I'm confident it was the best business decision, and I apologize if 50,000 programmers don't understand it and their heads explode and 100,000 bloggers run around saying I've jumped the shark.

I think Sean O'Donnell and Des Traynor hit the nail on the head. Wasabi seems to be simply a way to support more platforms without hiring more programmers, and if it only took 2 man months to create, that's an excellent trade off compared to having to double or triple your developer team.

If so, it is zero-risk because you can always take the generated code as a new base and quit using Wasabi and it will be as if you've never used it in the first place.

It seems to be simply a more sophisticated front end to a "common, or garden" code generator, a well worn concept used all over the place.

If Joel had called it a "code generator" (albeit with compiler-like interface) instead of a "compiler", would people have been so astonished?

Hmmmm, I hope Joel keeps blasting off at the mouth because I can't help but think someone at 37 signals is going to get an idea -

"Hey, let's write a bug tracking application."

I'm confident it was the best business decision

Obviously, it's your business, and you can run it how you see fit. However, the people reading your advice might get the idea that they should run their business like this, too:

http://listeningtoreason.blogspot.com/2006/09/5-reasons-why-joels-business-probably.html

spending two months writing a compiler that could preserve our [VBScript] code base

But it didn't merely *preserve* the VBScript code base. Wasabi is a superset of VBScript. VBScript is the *output* of Wasabi. Your code is now written in Wasabi: a new, proprietary language.

I'm not against VBScript. I'm against new one-off proprietary languages in a world of rich existing language choice.

Your argument against Wasabi seems to boil down to the fact that it's "beyond the pale," "insane," etc

My argument against Wasabi is this: when a developer decides the right solution to their problem is a new language, you don't have a solution. You have an even bigger problem.

So fine, Wasabi was a nice two-month fix for an immediate problem your customers faced. A few years later, at least to this outside observer, it doesn't seem like such a great long term-- or even medium term-- solution.

I know you prefer the Raymond Chen school of backwards compatibility to forced death-march upgrades. And I don't disagree with that. But sometimes you just have to roll up your sleeves and do what it takes to drag you customers-- and your business-- into the next century.

You said it yourself,Joel:

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.

Is FogBugz *that* different from the mainstream? Were there *really* no good off-the-shelf technology solutions for the defect management problem? You considered and rejected .NET in 2002 purely on the basis of timeline. What happened to the plan outlined here:

http://www.joelonsoftware.com/articles/Our.NetStrategy.html

1. wait until it's OK to require CLR,
2. port existing "business logic" classes to C#,
3. keep current web forms in ASP,
4. and create new web forms in ASP.NET.

So my question is this: is it Wasabi forever?

That plan was for CityDesk, not FogBugz.

Let's put it this way. You have these constraints:

(1) Six years of code already written in VBScript

(2) Needs to run on customers' Windows and Unix servers

(3) Minimize tech support costs

(4) Many customers refuse to install new runtimes on their servers, either because of IT policies or out of stubborness

What would be your solution?

rereading my (old) post about .NET, it looks like when I wrote that way back when, I thought we'd port FogBugz to .NET.

Since then, we added Unix support for FogBugz, so I don't think all the things I thought then still apply.

Right now, we could conceivably move to .NET by using the Wasabi compiler to generate C#, and require our customers to install Mono on Unix. (Still requires Wasabi, but we would throw it away when we were done with the last step).

I'm still curious to hear your business decision.

Has anyone actually used FogBugz? If so, you will run very fast in the direction of a href="http://www.atlassian.com/software/jira/"JIRA/a or something like it.

Bob

Well, well, doesn't it feel good to have a chance to pick on Joel? Makes you feel you are really somebody, doesn't it?

Sorry guys but when I see someone that has rightfully gained the respect of millions, do things that I don't understand or I find odd, I'd rather think that there's something I'm missing in the picture.

My bet is that Joel knows extremely well what he's doing.

Let's put aside the practical\business gains that Wasabi gave to Joel. Writing your own special-purpose language is only a first step in the process of gaining know-how for what's called Domain Specific Languages.
I've seen private special-purpose languages successfully used to generate huge C++ programs (250K lines) that do the job at hand in blazing speed, from a significantly smaller and easier to maintain source base (5K lines).

Yeah, I imagine if you are a Lisp or Ruby die-hard guru you could do the same thing in maybe 10K lines, but
(1) I BET the code will not be one tenth as understandable and maintainable as the one in the specifically tailored domain specific language.
(2) If you got yourself a new programmer you'd still have to train her to almost-guru level too before she would dare touch the code. In the private language case the language is tailored to the problem, so the code is simpler, so the new hire does not need to reach guru level to work with it.
(3) You'll never get the speed of C++.

Joel is actually exposing his business secrets just to keep us amused, informed, interested and sometimes even enlightened. Be thankful for it.

First, let me say that I do not agree with the blanket Joel-bashing that's going on in the comments. That certainly was not the intent of my post, and that's why I spent the entire first paragraph defining how important Joel has been in setting the tone for all the tech bloggers to follow him. As Des Traynor said above:

[..] even when he is wrong he is entertaining, and half the fun sometimes is in coming up with counter arguments in my head. [..] either side of this Ruby stuff he had written 3 great management articles, and an impressive guide on people management (recruitment etc), so the quality is there, just ignore the posts that could be perceived as flamebait.

Joel has always been an outspoken proponent of the "Programmer's Bill of Rights". However often we may disagree with him, Joel absolutely nails this part, and evangelizes it in a way that few other notable tech writers do. Plus he's funny:

http://www.codinghorror.com/blog/archives/000383.html

That said, the whole Wasabi and dynamic language saga makes me feel like I just walked through a sewer. It's not the kind of grand, intelligent softare lifecycle plan I'd expect out of a smart company like Fog Creek. That's why it's so jarring.

i like joel's writing, i *love* citydesk, never used fogbugz.

citydesk is so close to doing exactly what i needed (except one, unfortunatly, key feature) its amazing. I've ended up writing my own version to add a few bits I needed.

I wish it was as 'polished' as citydesk.

some of the more recent posts may have lacked some of the flair of the others but are still worth reading (i think).

as for the whole 'wasabi' thing (read 'Good Omens', it *also* has wasabi in it). well having written my own scripting language before (not a very good one but it works) there are perfectly valid reasons for doing it.

specifically when you spend 10 hours developing it, to get to the point you can code 'x' in 1 hour. if you do that every day the time to write the language is nothing, a throw away. especially if its 'in-house' and doesn't need the wide scope and capacity of .net etc.

i save time every day through my script language, since *it does what I need*, in this case i can write a report to query a database, pull specific data, sort it correctly and drop it into an excel template with one line of code. which i need only write once. it takes a few seconds to run that report. the development time was worth it, plus the language is easy to expand.

I'd think the abaility of wasabi to output a program into a windows *or* unix environment is worth doing, it sounds very much like writing a compatability library into an IDE, instead of calling it the IDE uses it to write whatever you want.

presumably if it just supports fogbugz, well its sort of like writing a big library to do the actual work, once you have that framework what you actually write in doesn't matter, the library does the work.

also if it pays the bills, i'd argue that in a deep meaningfull way... *how* you do it doesn't matter.

I'd love to work for a company like fogcreek, bar the minor facts that:

a, i'm in the UK

b, I'm not good enough at software development..

but I'll keep reading what joel writes, and blatantly pinching ideas as required, which explains a lack of writing on how the company actually runs...

:-)

"(1) I BET the code will not be one tenth as
understandable and maintainable as the one in the
specifically tailored domain specific language."

Be careful when making such bets against Ruby or
at least take a look at the couple of DSLs written in it.

Joel is actually exposing his business secrets just to keep us amused, informed, interested and sometimes even enlightened. Be thankful for it.

Pff. Joel is writing for Joel. It doesn't really matter if we're here or not. ;)

What would be your solution?

I think Wasabi forever is unsustainable.

Customers will have to absorb a little pain (install Mono or .NET, new version teething pains) in exchange for a little sugar (nice new features). I guess I'd have to balance the work effort vs. the sales upside of a new, rearchitected version of FogBugz.

we could conceivably move to .NET by using the Wasabi compiler to generate C#, and require our customers to install Mono on Unix. (Still requires Wasabi, but we would throw it away when we were done with the last step).

I've heard mono's UNIX support for C# and ASP.NET is quite good.

Again, it's your business. Not mine. But I think that's clearly the way to go. You'll probably have to refactor a lot of the generated C# code to get it to look like code human beings would write (or even a traditional ASP.NET app; not sure if that's a goal or even desirable in these circumstances). But that's still a heck of a lot less work than a total rewrite in another language. Which, based on the contents of your prior posts, I'm 99.9% sure you would never approve anyway.

At least with C#, new programmers' heads are a lot less likely to explode while working on FogBugz. It might also open up some extensibility points for community-written C# plugins, etcetera.

We use fogbugz a lot. It's an ok application, its main advantage being that it's cheaper to buy than it would be to develop something similar in house.

It's not doing anything amazing, the reports are poor and it's not quick, but it does the job. I reckon that a Ruby app that would do something similar just as well would take a few weeks.

I never trust languages that need to be compiled into something else, especially something else like VBScript that's interpreted at run time. You always get bugs that turn out to be with the conversion, not your code.

There is an 'Evil Empire' reason to do it though; by switching to Wasabi Joel has kept his poor VBScript programmers developing with a skillset they cannot take anywhere else. He can pay them less and yet keep high staff retention because nobody else would employ them.

Reading this is somewhat akin to listening to a bunch of Grannies yacking about a friend who's dared to suggest blue rinse doesn't look quite as good as everyone says and chose pink rinse instead.

Seems that the real mistake Joel's made was to dare to say anything but "it rocks" about Ruby.

A valid criticism might be he's based is concerns on second hand sources, although that Ruby has performance issues above and beyond what you'd expect for a dynamic language is something like an accepted wisdom.

But it strikes me that performance wouldn't be the biggest issue for running FogBugz on Ruby: bigger (given earlier posts) would be that customers need to install something else (mod_ruby, mongrel, lighttpd / FastCGI, whatever), that they're not already using, to allow the app to run. Beyond that, there's really nothing (technical) that justifies the lynch mob cries of "lunatic".

"You couldn't possibly have heard it, but that was the sound of fifty thousand programmers' heads simultaneously exploding. Writing your own language is absolutely beyond the pale."

If we did a straw poll of those 50,000, what percentage do you think we'd find have written some kind of HTML templating language that ended up being Turing complete? What about the _really smart_ guys who hid SQL behind their ORM api, then invented their own object query language, looking suspiciously like SQL then run around na ked whooping "mini languages rock!"?

Given that Wasabi seems to be a superset of VBScript, it may well have been relatively easy to implement. It's easy to find freely available VBScript grammar rules, you can use as a starting point ( for example a href="http://www.notebar.com/GoldParserEngine.html"http://www.notebar.com/GoldParserEngine.html/a - at the bottom). And being a superset of VBScrip eliminates 99% of the language design questions. It's "just" a matter of adding cool functional language features - and Joels not the only one e.g. a href="http://chumsley.org/jwacs/"http://chumsley.org/jwacs//a

"1. I don't see how Wasabi-- a language that, per Joel, compiles down to VBScript on Windows-- could actually be faster than Ruby."

To me it's not entirely clear if Wasabi is _directly_ executable or whether it only produces VBScript / PHP that you execute.

But if it _is_ directly executable and it's executing under .NET, it could very well be faster than Ruby (as in C-Ruby). The Phalanger guys, who re-implemented PHP from scratch to run under .NET (are they nuts?) claim significant performance gains: a href="http://www.php-compiler.net/Benchmarks.htm."http://www.php-compiler.net/Benchmarks.htm./a

And from everything Joel's said, Wasabi isn't actually shipping to customers - it's the generated VBScript / PHP that ships. So if it _is_ executable and slow, it's only annoying the developers.

"2. If performance is so critically important in this section of the code, why wouldn't Joel simply build that section of the code in a compiled language and call it from the other language? Am I missing something here? Is there some law that states all code for a web application must be in the same exact language?"

Yes you're missing something and yes there is a law: if customers have to install something non-standard, think carefully. To grasp that point, you really need to look at something like this: a href="http://freshmeat.net/projects/saxy/"http://freshmeat.net/projects/saxy//a

"The primary goal of SAXY is to provide PHP developers with an alternative to Expat that is written purely in PHP. Since SAXY is not an extension, it should run on any Web hosting platform with PHP 4 and above installed."

These guys re-implemented a PHP C extension in PHP because they couldn't rely on it being always available. Kind find a thousand more examples of that nature...

And Joel states the aim of platform independence - that compiled libary needs to work under Win32 / IIS and LAMP. So what are be talking here? Some C that can be compiled both into COM component _and_ a PHP extension? For drawing graphs? Writing Wasabi starts to look like a walk in the park by comparison.

"3. Justifying any language choice based on one tiny section of the code makes no sense whatsoever. [...] How does this make any business sense whatsoever?"

It's generating a chart right? Who likes charts most? Managers and bean counters - you know - the kind of people that control budgets / pay for software. Go figure.

"If performance is so critically important in this section of the code, why wouldn't Joel simply build that section of the code in a compiled language and call it from the other language?"

I thought the exact same thing when I read his anti-Rails rants.

It seems that it would be sensible to take a "best of both worlds" approach -- write an app in Ruby or Python, to save developer cycles, measure performance, and then rewrite the worst areas in C.

I assume that most of the people reacting with "Writing a new language? How absurd!" do not realize that writing a programming language, especially one that translates one language into another (such as a pre-processor) is not difficult. A simple version can be written in a weekend (try it), and a more complete version can be written in weeks. These are internal tools, not shrink-wrapped dev tools.

At last count, after ten years in the industry and another 25 or so dorking with computers, I've written three preprocessors (to add things like special-purpose generics and O/R annotations to Java back in the 90s, for example), five compilers, and two interpreter/virtual machines for professional work. They all had basically the same purpose as Wasabi -- I was going to be generating either 10kloc in my custom language, or 100k-1000mlocs in another language. Non-professionally, I've written about 10 languages, starting with an amazingly craptacular macro-assembler-crossed-with-fortran on my Atari 800.

Why is it that people jazz on about Lisp macros (which, honestly, were why I kept writing new languages, as I was aware of what Lisp and Smalltalk were able to do that would be difficult in c, c++, or Java) but get worked up over DSLs? They're just another way to leverage software.

I think it'd be nearly impossible for Joel to hire the "great programmers" he's always looking for if they had to spend their first year maintaining the feature parity between the php4, php5, and vb versions of his bug tracker.

In such a heated conversation and with so many replies, i doubt mine will even be read much if at all. I know this isn't the point of the article but you said Joel believes "teaching new programmers Java is liable to poison their minds." This is not at all what his article says. He says, as do MANY promenant programmers including at least one of the GoF, that teaching only java to new programmers is poisonous. It has turned the major of comp sci in many places into a java-only schools which do not teach flexable developing habits. Java is being taught as a trade. In academia, development should be taught as an adaptable skill. The difference is not small.

seriously, with the proliferation of pet programming languages in the open source world, why do you pick on Joel?

I've been considering making a language that has the sole purpose of ridding python of that stupid whitespace as syntax mindset.

---"It's a BUG TRACKER. What could it possibly be doing? Why is it so complicated?"----

It's got to add up all the bugs you've put into your program.

----"Rather than a project that I'd wager has got less than two man-years into it, admittedly two of their more valuable man-years by one of their better programmers, but probably by now, more than paid for itself."---

Two months as has been pointed out before (though I suspect it will grow cruddy and take more time).

Even if you don't care about Unix there are still problems with stuff done in .NET. For one thing you seem to need three versions (maybe sloppy application programming but still true).

Then there is the apparently huge footprint each .NET application takes. Look at how many megs of memory lookout takes (Outlook 2003 with Lookout and Spam Bayes takes up over 90MB on my machine.

I love reading Joel's articles, but the bastard abandoned further development of CityDesk shortly after I bought it.

Customers will have to absorb a little pain
(install Mono or .NET, new version teething
pains) in exchange for a little sugar (nice new
features). I guess I'd have to balance the work
effort vs. the sales upside of a new,
rearchitected version of FogBugz.

I'm sorry, but that is much worse than the solution implemented by Joel. Have you tried FogBugz under windows? You just run an installer. That's it. And, why, oh GOD why, do you want a new "rearchitected" version of FogBugz?

we could conceivably move to .NET by using the
Wasabi compiler to generate C#, and require our
customers to install Mono on Unix. (Still
requires Wasabi, but we would throw it away when
we were done with the last step).

I've heard mono's UNIX support for C# and
ASP.NET is quite good.

So, you don't really know.

Again, it's your business. Not mine. But I think
that's clearly the way to go. You'll probably
have to refactor a lot of the generated C# code
to get it to look like code human beings would
write (or even a traditional ASP.NET app; not
sure if that's a goal or even desirable in these
circumstances). But that's still a heck of a
lot less work than a total rewrite in another
language. Which, based on the contents of your
prior posts, I'm 99.9% sure you would never
approve anyway.

But, why do you insist in a total rewrite? I really don't understand that fixation in rewriting a perfectly good, working, revenue generating application.

At least with C#, new programmers' heads are a
lot less likely to explode while working on
FogBugz. It might also open up some
extensibility points for community-written C#
plugins, etcetera.

Who are this programmers you are talking about? FogBugz users? They don't need to modify anything, except one or two reports, and those are written either in PHP or VBScript. I've never heard of anybody's head exploding for using them.

Anyways, I always enjoy your writings, but this time I think you haven't quite understood the _business_ decision made by Joel.

Ouch, please forgive my lousy grammar in my last post :-(

Didn't 37signals take a similar stance as Joel, when they decided to build the RoR framewoek instead of just using a more accepted web-friendly language such as PHP or .NET.

I know it's not quite the same as developing a full-blown lanugage/compiler, but I'm sure VBScript/Wasabi is just as similar for Joel and FogCreek, as Ruby/RoR was for 37signals. It's a vision of keeping development time to a minimum, while meeting other goals .. The main difference in those other goals are that Wasabi sounds like it has compromised on re-use across applications (it's tailored to FogBugz) while supporting various frameworks/platforms, where as RoR has compromised on portability (without installing it's framework) and run-time speed but is re-usable across many application types.

The key is that 37signals decided to let the framework/toolkit/language go open/mainstream, and since then it's been adopted widely and hence is now becoming a popular, more mature framework. It would be pointless for Wasabi ever getting even out the door of FogCreek, since it's tailored to developing 1 app.

Where do you guys think languages come from anyway?

Some guy (Matz, Gosling, Wirth, van Rossum, etc.) decides to create his own language because he doesn't like the existing ones.

Are we seeing the emergence of a framework: Wails on Wasabi?

I used to have Joel On Software as one of my daily favorites. Then Joel went on a long batch of posts that were basically advertisements for his software, and he lost me forever. It used to be that he would post interesting tech posts that developers could appreciate. Now his blog seems to be a marketing pitch that doesn't grab my attention at all.

I don't understand the aggressively of the posters and blog have toward Joel. I mean really! It's like the guy killed your puppy! Why do you care so much that you need to crucify him for it?

The only thing I can think of that could trigger this is that the posters must be big fans of Ruby and all these web technologies, and writing a Yacc grammar must be some really scary "voodoo" thing. People must be really insecure with these basic tools and need other people to write all the tools for you.

As Art Taylor wrote above, lex/yacc really easy. Plenty of us do it. Converting code automatically makes sense and it's safe.

I don't see why you couldn't vbscript to code that looks like it was written by a human. VBScript (not visual basic) has a some weird cases to be careful with but such converter doesn't need to be totally generic and handle all the coding tricks in the world, only the ones needed by the company.

It's already written in his article that the 'compiler' has no libraries and is not a VM. It's just a converter. Don't go ballistic based on speculations.

..and about Quake C. The goal of Quake C was to have a custom language for a particuliar audience, the mod makers, people who are not technically minded yet needed to write scripts that would run quickly, just to sequence calls of the API with basic logic. It was not to have a totally generic language, it was to have a CONTROLLED one, and one that has security built in.

Again, not all programmers think writing an interpreter is an unconceivable task that violates all common sense.

After that, as the requirement went up they gave up the scripting and switch to just using C++, which exclude a large class of users.

Lame. With your attitude, no new languages would ever be written. There's nothing inherently wrong with Joel or anyone writing a new language, it all comes down to whether you think you can improve over what's come before or not.

In such a heated conversation and with so many replies, i doubt mine will even be read much if at all. I know this isn't the point of the article but you said Joel believes "teaching new programmers Java is liable to poison their minds." This is not at all what his article says. He says, as do MANY promenant programmers including at least one of the GoF, that teaching only java to new programmers is poisonous. It has turned the major of comp sci in many places into a java-only schools which do not teach flexable developing habits. Java is being taught as a trade. In academia, development should be taught as an adaptable skill. The difference is not small.

Agreed, you need to correct this Jeff. What you said is plain untrue and anyone who follows that link will see that.

I just wanted to highlight this because I agree 100% with Joel's view on this particular subject.

Most of the comments here make absolutely no sense to me. If Joel's team developing their own language is such a bad idea, how can somebody deciding to write their own language (Ruby) be a good one?

I don't see Wasabi being a bad thing, if it works the way Joel needs it to; it allows them to design and build their product, and their product apparently earns them considerable money. I mean, a recent article on JOS showed a picture of the staff at lunch, and I sure saw more than one person there.

There are lots of programming tasks that need to basically take input in one manner and produce output in another. ASP.NET itself takes code in one of several languages and produces HTML output.

I don't see this as being any different from having to export data in multiple formats (XLS, XML, text, whatever). You don't do that over and over again by hand, cutting and pasting back and forth, do you? No. You write your own *proprietary* application to do the work and produce the output. I don't see Wasabi as being much different - you write the code in a VBScript-type language and it produces output as VBScript or PHP or whatever.

And for all of you criticizing Joel's decision regarding Wasabi from a business standpoint - blow it out your ears. It isn't anyone's place to try and make *business* decisions other than the person responsible for that business itself.

And no, I'm not defending Joel. I don't agree with everything he's written, and he's perfectly capable of defending himself. I just think that the majority of the comments here (and Jeff's article itself) are ridiculous. (And Jeff - I read your site every day and usually agree with you; I even got the sticker. g)

I stopped reading at the first mention of the word Ruby. While skeptical, I was considering your POV, even after reading thru parts such as "...although I think Java is..." (who TF are you and why should I care what you think? it's either objective or subjective, pick one and stick with it!). But once you mentioned Ruby, your ultimate motive for this attack, it was game over, your article became the digital equivalent of toilet paper.

it doesn't appear that this can will get shut anytim e soon.

When Joel was cycling around the world (he has done that!), we were writting thousands of SLOCs. So don't he come saying he's an expert or something.

Ok...you DID read all of Joel's post, right?

And you did read the earlier articles where he'd mentioned Wasabi, right? (this wasn't, like, newly leaked material)

And you all DID catch the part where Joel explicitly said that wasabi "compiles down" into PHP and VBscript, right?

To me, that means he wrote a script parser...albiet a very intelligent one that fit a definate business need.

Not a whole programming language. Not something that compiles down to the bits-n-bytes level.

Jeff...I love your stuff, but man...lay off the wasabi. =^)) I don't agree with everything Joel says either (the conspiracy theory on VMware almost made me laugh out loud) but I think that you may have jumped the shark on this one!

(ps. Umm...being an uncultured pac nwesterner...I haven't a clue what "jumping the shark" means...)

Go in peace.

Jeff, I gotta tell ya. The joke's on you.

It seems you (and everyone in the "I can't believe he is making his own language" camp) haven't realized so far that Wasabi is not a language in which FogBugz *runs on*.

It doesn't matter if Wasabi-as-a-implementation-language sucks. If it is slow, or if only 3 people in the world know how to use it. What matter is the point that Wasabi is a tool to provide portability, generating code that can run on the "most deployed plataform out there", whatever that is.

Funny thing is, I used to come to your blog from time to time. But this post made me realize that a) you are seriously lacking in reading comprehension and b)seeing your failing to understand the point of Wasabi, you may as well have a .NET/Java-poised mind, something that lowers you score somewhat with any respectful developer.

I think the phrase "jumped the shark" has jumped the shark.

Also, I notice nobody has answered Joel's question:

"Let's put it this way. You have these constraints:

(1) Six years of code already written in VBScript

(2) Needs to run on customers' Windows and Unix servers

(3) Minimize tech support costs

(4) Many customers refuse to install new runtimes on their servers, either because of IT policies or out of stubborness

What would be your solution?"

I imagine nobody has answered it because they can't. I know I can't. Why? Because most of us have never been in the position of "oh shit, I have a successful product and now people want to run it in environments we never intended it for. What do I do to capture those sales?"

That would be a great problem to have, really. Joel did what he figured would give him the biggest return on the labor. Does it seem a little goofy? Sure. But it appears to have been effective as hell.

Isn't that what really matters?

Jeff, I gotta tell ya. The joke's on you.
It seems you (and everyone in the "I can't believe he is making his own language" camp) haven't realized so far that Wasabi is not a language in which FogBugz *runs on*.

It doesn't matter if Wasabi-as-a-implementation-language sucks. If it is slow, or if only 3 people in the world know how to use it. What matter is the point that Wasabi is a tool to provide portability, generating code that can run on the "most deployed plataform out there", whatever that is.

Funny thing is, I used to come to your blog from time to time. But this post made me realize that a) you are seriously lacking in reading comprehension and b)seeing your failing to understand the point of Wasabi, you may as well have a .NET/Java-poised mind, something that lowers you score somewhat with any respectful developer.

Raphael on September 13, 2006 09:00 AM

Amen. Beyond that, since Wasabi = VBScript + Extensions (http://www.joelonsoftware.com/items/2006/09/01b.html), I'm sure there would be quite a few more than "3 people" who could pick it up. This brings up a few more points:

1. If you will be doing code-generation, it seems quite logical to me to base it on a language that alot of people would know instead of coming up with a completely new langauge.
2. Successful products tend to outlive frameworks, so porting/refactoring/upgrading/maintaining are real issues that, although distasteful to many developers, are crucial to making staying in business.

There's a huge difference between making v.5 of an app with a hefty installed user base and making v.1 of 20 apps in the latest/greatest language/framework which will never see v.2.

If there is one thing I have learned over the years it is this: the best technology does not always win the market. In fact, most of the time it loses.

Let's say I come up with some fantastic new product that is fully buzzword compliant and uses all the latest technologies. But my competition releases a similar product based on old technology but beats me to the market by three months because they used a bunch of (proven) legacy code to build it. Do you think the end user really cares if the back end is based on python, ruby, or C# .NET 2.0? No, they want to hit the button and have the product do what they paid it to do. And if it does it in 0.004 seconds instead of 0.002 seconds, they don't notice/care.

The point is, Joel is in the software *business*. He's not some abstract CS professor trying to find the most elegant and complete solution to a problem worthy of peer review, he is trying to give his paying customers what they want as fast as possible in order to make a profit. While everyone is pointing out technical flaws that have no effect on the end user experience, he's raking in the cash.

It tickles me how people try to criticize something that they know *nothing* about. There are, maybe, 1000 words published about Wasabi.

How in the hell would you presume to understand the problems they faced? How would you presume to understand the solutions they debated?

It's like someone in these comments saying that the real joke was that they had a report that needed millions of calculations, and how could this possibly be needed in a bug tracker.

Once again, an example of Uber-Ignorance. It's the "I don't understand this so I'm just going to say IT'S BAD!!!" Puh-leese.

Here's a tip: Don't run your mouth when you don't know what you're talking about. Frankly, I don't think Joel got where he is today by making poor decisions. And I really doubt that they were sitting around one day and said "you know this vbs code is nice, but lets just reprogram it all in a brand new language that we can invent!"

What I love the most, is that Joel has talked for years about "Thistle" -- a compiler to convert VBScript to PHP4. Everyone thought that this was just the cats pajamas. Thistle this and Thistle that.

Wasabi is essentially the same thing. The only difference is that instead of programming in VBScript, you're programming in a VBScript-like language which includes features usually reserved for more powerful languages.

GET OVER YOURSELF.

It tickles me how people try to criticize something that they know *nothing* about. There are, maybe, 1000 words published about Wasabi.

Joel himself criticizes Wasabi-- and for many of the same reasons I do. Here's a direct quote from Joel:

That said, there are major drawbacks [to Wasabi]. 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.

Joel's new favorite expression: CRICKEY! :)

Deployment, deployment, deployment. Joel has his priorities right. Why do ISV's struggle for oxygen while Web 2.0 companies breed like rabbits and get fed huge fricking carrots? Deployment.
Everyone has a web browser that is just good enough to do some interesting things that feel like interactive, seamless experiences. Thousands of engineers are writing code to use these web browsers despite the completely obtuse programming model and slow speeds.
This is because many users and corporations refuse or are too lazy to install software, and that practice is growing. If Joel wishes to remain an ISV his software must be nearly as easy to deploy as a web app. All other considerations are secondary.

Finally after reading a lot of hysterical posts, it seems that Wasabi is more or less a code generator.

What about the DRY (Don't Repeat Yourself) principle, and the use of code generators, advocated by the Pragmatic Programmers?

In this case, does the benefit of DRY outweigh the burden of future FogCreek programmers learning and maintaining Wasabi? If so, maybe Wasabi's fine.

OTOH, if Wasabi is just doing simple code generation to multiple targets, maybe standard scripting tools would suffice for that purpose.

I do find it interesting that the longest post I've ever seen on Coding Horror has to do with a company creating their own proprietary language; this seems to have drawn out the ire of a vast number of developers who are quick to say "that's stupid; just use C# or Java or Ruby".

Creating a proprietary language has a number of excellent attributes. I proposed just such an approach at a prior employer and we went through many discussions about it; the employer provided a software platform that was sold to our customers who then configured/customized it to run their own applications. This meant a great deal of development went into each project AFTER it left our development team. Competition was quite fierce in that market space and trimming customization and upgrade time for customers would have been a HUGE competitive advantage - competitors whose platforms customized quickly (unlike ours) and easily (unlike ours) got glowing reviews from the industry pundits like Ga^+n3r. At the opposite end, since we forced our customers to use C# or Java or C++ or VBScript to customize it meant that _we_ had no control over the language and could provide no upgrade support if we changed underlying APIs, built a new server architecture or any number of other enhancements; had we used our own language we could change the meaning of the instructions - i.e., compile them to use the new APIs as opposed to the old ones. But with general purpose languages as the customization tools, the customer had to refactor all API accesses by hand. This put huge constraints on our ability to extend our product suite and/or modify APIs causing us huge RD expense. Additionally, since customers had to customize in a general purpose language rather than a domain specific language tailored to the programming tasks they would be facing, their development, maintenance and upgrade time/costs expanded. Customers had to use one language for server customizations and another for browser customizations, each of which had its own APIs. A proprietary language could be compiled to a language suitable for the server and to another language suitable for the browser enabling the customer to perform all customizations in the same language with the same business model abstractions. The business drivers for using our own language were tremendously enticing.

Of course, I'm sure the business people out there can guess why we never did create our own language and why we foisted a low level language off on the customers thereby (likely) tripling their customization time/cost and proably quintupling their upgrade time/cost. The reason we didn't do this was a number of myopic senior developers who quailed at the idea because (and I paraphrase and insert some personal opinions of what they really meant inside square brackets) "a proprietary language will be so slow" or "it will be too hard [for us] to maintain" or "people [i.e., us] won't want to use it because it is relatively unknown [and won't look good on _our_ resumes]" or "it will take too long [for us] to build applications with it" or my personal favourite "programmers like those who work for our customer [i.e., us] want to program in C# and work with MS DataSets; they [i.e., we] don't want to use [i.e., have to worry about building] domain specific abstractions".

I guess the point I'm trying to make is when developers attack somebody's idea, such as Joel's Wasabi, without knowing, let alone _understanding_, the business drivers that led to that decision, they only make themselves look like fools. I don't know Joel from a hole in the ground, I don't know his product and have no bias for or against him. I just find it a continual source of amusement (and irritation) when people lash out about things they know little to nothing about.

"Let's put it this way. You have these constraints:

(1) Six years of code already written in VBScript

(2) Needs to run on customers' Windows and Unix servers

(3) Minimize tech support costs

(4) Many customers refuse to install new runtimes on their servers, either because of IT policies or out of stubborness

What would be your solution?"

Well, first of all, I'd note that PHP is a runtime not installed by default on UNIX webservers, particularly not if you're talking about those in use in corporations, thus making 2 and 4 mutually exclusive.

When Joel puts this article into his next book, then you know for sure he has jumped the shark ;)

Brendan,

"Games were CPU limited and memory was scarce. Python may seem like it has a small footprint now, but it wasn't that small back then...especially in games."

Right, which led the ids and Epics to write their own custom solution. The context was games, and when I said that Python and other languages weren't serious alternatives to writing your own thing from scratch, I meant it in that context. I know that Python is quite old and that many organizations other than game companies have used for a long time.

_Code Complete_ by Steve McConnell suggests using code translators on page 499 (of the first edition), and says "...A translator is useful when you have a large code base that you're moving to another environment." This is the problem that Joel was looking to solve.

Furthermore, _The Pragmatic Programmer_ by Hunt and Thomas include code generators as Tip #29, and Domain Specific Languages as #17, which both relate to Wasabi as well.

Jeff's reaction must be based on a misunderstanding of the problem Joel was solving and how he solved it, because his own blog's patron saint seems to think Joel's approach is reasonable. If Wasabi is the next generation of "Thistle" then I think it's consistent with what McConnell, Hunt and Thomas advocate.

We use FogBugz at our company and the fact that it didn't need me to install and configure additional runtimes made my day much less stressful. Having tools that install painlessly is something I think is part of "The Programmer's Bill of Rights". If Joel can make a version of FogBugz that not only runs on Unix, but maintains feature parity with the Windows version, AND will use a runtime that probably already exists on the customer's machine, then he's giving me that Right.

McConnell's recommendation of code translators goes on to say:

"The hazard in using a language translator is the same as the hazard in using a restructurer: If you start with bad code, the translator simply translates the bad code into an unfamiliar language."

Wasabi, as I understand it, solves this problem because it was written to translate *only one application*--FogBugz--which was written with a Hungarian notation that made it easier to mechanically translate.

When I look at the VBScript source code of FogBugz, I can see lots of comments and clean and easily readable code. Whatever Wasabi is, its output is anything BUT an unfamiliar language.

What would I do? Well there's no way to answer that without more information.

How many units of FogBugz are sold to Unix customers vs Windows customers. What percentage of his Windows customers absolutely refuse to install ASP.NET or other technology?

What is the productivity gain or loss in not having an integrated IDE for Wasabi? As far as we can tell from what Joel posted, Wasabi is the language they write code in.

I think "little languages" make a lot of sense, and to echo another poster, anyone who has ever looked at Smarty or another template engine and made their own instead is partly down that road already.

Think about it: you're paying five developers to sit there banging on the keyboard all day. They could either be programming efficiently, writing one line of code that does the work of ten, or sticking doggedly to vanilla VB/PHP and using only basic constructs.

A good example of this is the way people normally talk to RDBMSs: three to five lines of initialization and setup code, three more lines iterating over the result set, etc., when a terse system like K/Kdb just treats database tables as built in objects and gives you a couple of short operators to iterate over and scan them.

If you have a few brilliant programmers at your disposal, why not smooth down some of the rough edges of your chosen language and let the computer emit and handle all the nasty details?

As for the Joel bashing, in the immortal words of Malibu's Most Wanted, "Don't be hating!"

Please separate the argument from the personal attack. Seriously.

I'm going to go out on a limb here and guess. My guess is that the sales to Unix customers is negligible when compared to Windows sales. I think eventually moving to ASP.NET as per Joel's original plan still makes a lot of sense.

Unix customers who refuse to install Mono will find another solution. Can't be all things to all people, right?

Benefits of ASP.NET

- Improved IDE over Wasabi's IDE.
- Improved productivity.
- I can't speak for FogBugz developers, but I wonder if they enjoy writing C# code over Wasabi. If so, then that would be a benefit.
- Easier to develop an extensibility model as Jon mentioned.

As Jon said, we use FogBugz at work and I've pushed to keep it over free solutions. From an end-user perspective, it's great.

However, I don't think they've built as enthusiastic a developer community around the product as they could. Build a simple extensibility model and watch the plugins roll in.

Look at Windows Live Writer which is totally Beta and buggy, but at the same time is inspiring tons of plugins. Wordpress is another example where there is a lot of enthusiasm for developers to build around a product.

Just my $0.02

I think Joel's mistake with regards to his Ruby criticism is to lump dynamically typed languages together with them.

Python has show itself in recent tests that I have seen poking around the blog space to be quite a speedy contender. The fact that it coupled with Django power some pretty mighty newspaper sites appears to bear out it overall robustness for the problem space. Or am I wrong?

Joel's use of his own programming language is sad. It reminds me of a small company called Ontario Systems in Muncie. Not a bad company, but it codes everything in a programming language called Mumps (http://en.wikipedia.org/wiki/MUMPS). While not its own language, it is quite rarified. Quite a few CS graduates from the local university, Ball State (http://www.cs.bsu.edu), go and work there for a while after school. More than one hated using Mumps because it didn't help them build skills that were useful in many other places. In some ways, the felt it could result in career lock-in and they didn't like that. Perhaps that's another reason for using Wasabi.