Has Joel Spolsky Jumped the Shark? (2006)
codinghorror.com
codinghorror.com
> 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?
Anyway, whether it was a good solution or not, I don't quite understand the need that some people had to pick on someone so harshly. I never really followed Spolsky's blog but as far as I can tell it was pretty tame and respectful. Am I missing something?
Edit: Also, a compiler from one high level language to another is not the hardest thing in the world to write. We've got college kids these days writing new languages that compile to JavaScript. Maybe this was viewed as more of an extraordinary engineering feat back then or something.
And that totally ignores the absolutely massive benefit of having a community around your language of choice. Libraries, bug fixes, googleability, a pool of programmers to hire from, etc, etc, etc.
Sometimes, sure, the right move is the least worst decision. But that doesn't excuse it for being a bad solution in general.
Fierce discussion isn't harsh, it's just that the underlying topic is so interesting that people feel inclined to pick apart the pros/cons extensively until they arrive a brick wall of pure disagreement.
But it didn't end there. Joel had then converted his entire audience to seed Stack Overflow - the one invention that had the biggest impact on the programmer productivity in the 21st century. That's one hell of way to jump the shark, a gold-medal level performance. We would be lucky beyond measure if that sort of "disaster" happened to us every four years, or even each decade. But we're not so lucky.
Hats off to Joel Spolsky.
Not to mention, Stackoverflow was seeded initially by Atwood's audience (since he was the developer of the project to start with). I know because I was one of the first users back in private beta.
Both Joel on Software and Coding Horror readers formed the initial audience.
While Jeff wrote code for StackOverflow, and Joel did not, Joel provided and acquired the initial funding to pay for Jeff's work, and hired the other talent required to allow the site to launch. It was neither entirely Jeff nor entirely Joel's creation, and I doubt it would've been able to launch without both putting quite a bit of backbone into it.
I believe he also primed the pumps a couple of monthes in advance with Codinghorror, I was reading both at that time.
[1] http://www.codinghorror.com/blog/2008/04/introducing-stackov...
Atwood then goes on to call it "crazy town."
Am I the only one who thinks that this decision might've paid off down the road for them? It sounds like he was just trying to code his app in a way that it would work in multiple types of server stacks, rather than trusting that MS wouldn't break their backwards compatibility again after doing so with ASP.net.
Maybe I'm wrong. I'm curious what the people who know way more than me think about this. I knew next to nothing about web apps in 2006, other than dabbling in PHP as a side note in a MySQL class.
At the time, Fog Creek consisted of three people and one summer intern. We couldn't afford to rewrite all of FogBugz in some other language... even if there was a language (in 2003) that was reasonably portable between Windows and Unix, which there wasn't. (Yes, we considered PHP. That would still have been a full rewrite, and PHP on Windows was crappy and increased the system requirements in a way that our customers wouldn't have liked).
Yeah, a Lexus is better than a Camry, but not everyone can afford Lexuses. So saying "you idiot, why are you driving that crappy car, it's obviously crappy" is not particularly insightful... the question is, if you can get 90% of the bang for 10% of the bucks, that's a pretty good decision as a startup, even if it seems strange.
What's more interesting about the reaction is that so many average programmers seem to think that writing a compiler is intrinsically "hard," or, as Jeff wrote in 2006, "Writing your own language is absolutely beyond the pale." To me this sounds like the typical cook at Olive Garden who cannot possibly believe that any chef in a restaurant could ever do something other than opening a bag from the freezer and dumping the contents into the deep fryer. Cooking? With ingredients? From scratch! Absolutely beyond the pale! Compilers aren't some strange magic black art that only godlike programmers are allowed to practice. They're something you learn how to create in one semester in college and you can knock out a simple one in a few weeks. Whatever you think about whether it's the right thing or not, if you think that a compiler is too hard to do as a part of your day job, you may want to invest some time in professional development and learning more about your craft.
I haven't written a compiler since I took the course... but I've written a lot of interpreters. And as the course will teach you, they are used everywhere, for a lot of things, even things you wouldn't expect. An HTML renderer, for instance, is basically an interpreter for the language called HTML, interpreting it into graphics commands. (Adding JS to the mix complicates things, but that's a decent understanding of a straight-up HTML renderer.)
For something a little less formal, Jack Crenshaw's "Let's Build a Compiler" is a good introduction: http://compilers.iecc.com/crenshaw/
Compilers aren't black magic, but anyone who's never written one seems to think they are.
Given that languages have developed quite significantly since 2006, if you had to make the same decision in this day, what would you do?
I learned more about the fundamentals of programming in one semester of compiler design than I did in the rest of 4 years of courses. It ought to be a requirement for any comp. sci. degre, IMO.
Java, of course, is so careful to protect global namespace that all kinds of "patterns" for disguising global state as something else emerged (woohoo "Singletons"), resulting in tools to find them and force them to be further disguised.
Another interesting thing (recall PG's aphorism that any sufficiently complex project contains a half-assed implementation of Lisp) is that designing ridiculously complex declarative syntaxes ("data") isn't considered beyond the pale on many projects (or at least it's allowed to happen through carelessness), but creating a properly defined language is.
This actually predates PG - it's known as Greenspun's Tenth Rule[0]
> We had a large code base in VBScript that only ran on Windows, and almost no developers.
So you roll your own language to improve things?
> Yes, we considered PHP.
I don't think you did.
> That would still have been a full rewrite, and PHP on Windows was crappy and increased the system requirements in a way that our customers wouldn't have liked.
Full rewrite into a cross platform language which only went on to improve and would have been far more backwards compatible [with a small eventual migration to php5]. I'm sorry but the fact you can't write a decent install script or manual to get your system working in different environments is not reason enough to roll your own language. Yes developing the compiler didn't take long but now you have a zero'd recruiting pool, a slower debug loop and an eventual fragmented maintenance nightmare. Oh and by the way, saying "PHP on Windows was crappy" is not particularly insightful...
> Cooking? With ingredients? From scratch! Absolutely beyond the pale!
It is when you're working at McD's though, and that is what Jeff everyone else was trying to tell you.
> What's more interesting about the reaction is that so many average programmers seem to think that writing a compiler is intrinsically "hard,"
We didn't react because we're average and think writing a compiler is hard, we reacted because you went against every common sense principal of software development there is. Any idiot who completes a degree can build a compiler / code generator, that doesn't mean its a good idea for your next web app. But go ahead, call us "average" delude yourself more, everyone who doubts you is just stupid because, well you're just such a godlike programmer.
I don't get it, its obvious, you're an MS flake, because of that you didn't want to use the logical choice, PHP, so you did something stupid. And now you can't just own it, instead you going around insulting everyone who calls you out. The best developers own their mistakes and learn from them, the bad ones flail around, blame the language, system, or other people.
Please dont write posts like that on HN.
I've worked on compilers for a long time and the AST generation is typically the easiest part.
Optimizations, and different target backends are easily an order of magnitude harder.
That's why every new language typically begins as a simple AST tree walker, that's the easy part.
They can they "graduate" to byte codes and then to asm generation if appropriate.
AST generation is usually simple. It's the conversion to the other language that usually get's difficult.
Also, targeting different backends is drudgery but I never thought of it as being hard.
Ah, ok. In that case, I'd agree.
Considering that most of the original code base was using ASP (there was no .NET when they started), this meant that all of their source code had to be shipped with the product. They couldn't just ship binaries. So part of me wonders if the Wasabi idea was a way for them to have obfuscation and some protection against piracy and competitor knock-offs.
[1]: http://www.codeproject.com/Articles/9738/Introduction-to-Mon...
Software is all about spending a fixed amount to produce it and then selling it over and over and over. If you double that fixed amount and double the over and over and over, you doubled your profits. Writing once and compiling to two things is less work than writing the same product in two different code bases as well. That sounds good and ignores things like buying a magazine ad becomes more efficient because more people who see the ad are potential customers.
As an engineer, I sure as hell wouldn't want to work on a system written in Wasabi. But as a business person, or an employee getting equity or options, it might make sense.
edit: Apparently it is, as of 2010. http://fogbugz.stackexchange.com/questions/210/is-fogbugz-7-.... Also, a 2011 Quora answer by Spolsky: "Much of the FogBugz code is still in Wasabi but a lot of it is in C# now." http://www.quora.com/Joel-Spolsky-Are-you-still-using-Wasabi...
Kiln is pure C#/Python, Trello is pure CoffeeScript, and so on. Wasabi solved a porting issue. It wasn't designed for and isn't used for new stuff.
I was shocked at how bad the software actually was in so many aspects. I was shocked because it was Joel who has been constantly talking about how to hire the best developers in NY so naturally my expectations were quite high.
Reflecting back on all of this, I'm sure the software probably wasn't bad, it's just that through Joel's amazing writing he has created very unreasonable expectations.
The lesson I've learned from it was to lower expectations of my users before they use my software, and then exceed them.
Spolsky's writings have always seemed to me to be completely vapid and obvious, at best.
To see what a great reputation he has among pointy-headed bosses and developers alike is a sad comment on the state of the industry.
That his company writes crappy software should surprise no one.
Edit: toned it down.
The lesson I learned is that people who write a lot of interesting things about software development (I've read almost everything on Spolsky's site) don't necessarily create good software themselves.
"[H]ow to translate [this bit of VBScript] a(1), which could mean "look up the 2nd element of array a" or "call the default method of the object a passing the argument 1" depending on what type a contains at runtime? This really matters, because we use arrays, and because we use the built-in class RecordSet all over the place, doing things like rs(1) which is short for rs.Item(1).Value, and since VBScript is latebound there is no way to know what code to generate in PHP until runtime, and that's too late! The only correct thing to do in PHP would be to generate code that checks the type of a, and decides, at runtime, whether to do an array lookup or a method call. This is messy and slow and would suck big rocks in the kinds of tight loops where you tend to be using arrays.
How did we fix it? Well, thanks to Hungarian notation, so callously dissed by developers who do would not recognize a superb coding convention if it walked up to them on the Shanghai Maglev train and shook their pants leg, every recordset at Fog Creek starts with the letters "rs". And Thistle looks for the rs and say, "ah, this is a recordset, you're not looking for an array value, you're calling the default method," and generates fast code. Based on your age you will either call this an evil hack (if you're young) or an elegant hack (if you're old); in either case it's a huge optimization made possible by the fact that Thistle only has one program to compile. Outside of Fog Creek it wouldn't work. All hail Hungarian notation!"
I wonder if any of his intern developers switched career after working there :|
http://www.joelonsoftware.com/items/2006/09/01.html
Interesting to see Joel's comments on web stacks built with Python and Ruby back in 2006, and even taking a snipe at Lisp. I really can't decide whether web development has fundamentally advanced in every way in the past 5-8 years, or whether it's essentially the same.
The whole Wasabi story sounds eerily similar to this classic Daily WTF: http://thedailywtf.com/Articles/Classic-WTF-We-Use-BobX.aspx
Later, Thistle was broadened out into an ASP to PHP compiler. Compiler was still a loose term; there was still a lot of regex magic that relied on you following Hungarian apps notation. That said, I'm fairly confident that this version of Thistle did build an AST for code generation, which does mean it qualified as a real compiler.
That matters because this version of Thistle was extended out with two additional features: it could compile VBScript to JavaScript, and it added some conveniences to VBScript, such as macros (called picture functions (don't ask)), lambdas, and simplifications to the declaration system. Don't laugh too much at the former; the motivation was the same as for RJS or Seaside's JavaScript support. All three technologies are dead now, and for good reason, but it was modish at the time.
Later, when .NET came out, and VBScript was end-of-lifed, that left us with the option of rewriting the whole thing...or making a "real" compiler that could compile VBScript to .NET. Wasabi was born. Wasabi was written as a proper compiler that could translate VBScript to C# and (for legacy reasons; see above) JavaScript. Wasabi, unlike Thistle, was a real, full-blown compiler, in a CS sense, so it was feasible to add type inference, lambda expressions, and several other niceties, without spending too much effort. That said, the goal here was to allow transition: new components, with restrictions, could be written in C#. The idea was that, at least hopefully, Wasabi would gradually be deprecated.
So no. It was never meant to be a new language. It was always intended to be a stepping stone, a translator between languages, not a real language in itself. While it gained some additional features, that was to make working in the damn thing palatable--not to be a real language in its own right. Emitting C# and .NET IL are actually about equally easy if you have a real compiler, but Wasabi always emitted C#, specifically so that we could one day ditch the whole thing.
O_o
There are a few things that I think sound wrong, things like performance comparisons with Ruby, although I wasn't doing web development in 2006, and I'm sure it was a very different time.
However I don't think Jeff was entirely fair to Wasabi. He picked on it compiling to VBScript, but I think Joel explained clearly that it was only one of the possibilities, and in fact PHP5 would have been a perfectly good target to compile to.
I think we have a lot more choice now for web applications, and therefore I don't think it's justified to write your own compiler and language in-house anymore for something like this. However at the time, I think what Fog Creek did with Wasabi was a good decision, and actually quite inspiring.
Try that in Javascript or PHP and see if you can fit the whole thing in 15 minutes (the YouTube upload limit)
Sometimes designing your own language is just the right thing to do.
I had to check that the blogpost wasn't an April 1st submission because the entire premise of writing a toolchain to get cross-platform compatibility out of Visual Basic has get to be April Fool's material. The fact that the language is interpreted from VB into other languages that might generously be described as "partially good" (like JavaScript and PHP) just takes this whole thing over the top.
in other words my mind is blow (as per Atwood's comment) that the goal of cross-platform compatibility wasn't achieved in a sane way, like just using Java or Python.