a companion discussion area for blog.codinghorror.com

Has Joel Spolsky Jumped the Shark?


#41

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


#42

Dude, that Joel WTF picture is totally going on my wall at work. Another good one:

http://technomancy.us/images/joelonshark.jpg


#43

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


#44

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


#45

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.


#46

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


#47

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.


#48

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.


#49

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?


#50

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


#51

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?


#52

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?


#53

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.


#54

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


#55

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.


#56

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.


#57

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…

:slight_smile:


#58

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


#59

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

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.


#61

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.