Back in the late 90’s I was advised not to learn Java because it would never be “fast enough for any serious web application”. So now it seems odd to hear Java being held up as the faster language.
It’s a good thing I didn’t listen back then and I imagine Ruby developers will do the same thing we did in the early days of Java… throw hardware at it until Moore’s law catches up.
Customers aren’t being unruly if they’re expecting a product to install straight from what comes out of the box, and–in corporations–without installing something that will cause a problem peculiar only to those environments (like licensing, security, and a need to institutionalize the knowledge to maintain it).
Our company happens to be flexible, so if FogBugz required Ruby on Rails I could find a machine to do it. That said, my comfort is still inversely proportional to the number of dependencies a tool requires, and therefore I would be one of Galloway’s unruly customers, and Joel would have to fire me.
There exist companies that “damn the torpedoes” and deploy their applications on young and next-gen platforms, even if it means a lower market penetration. There also exist companies that don’t do this, and a consequence is that their products fit a different market.
I’m obviously not an unruly customer, because I think breaking backwards compatibility is something to be taken in moderation. It is not a wise business decision for US to replace technology at the same frequency that new products are being developed. We skip versions. We wait for the first service pack. We even waited a year before switching to .Net 2.0 for our in-house projects because that was the schedule that suited us.
The quality of this discussion over Wasabi seems to be related to how seriously you take Joel’s requirements, because when they are taken seriously “Wasabi” is no less absurd than chosing to “fire” half of your customers.
I think his posts have been part of an elaborate joke that has yet to play out fully…
Yeeeah, when Joel posted about his favorite Firefox plugins, I knew we were officially hitting rock bottom. Joel is scraping for content.
Maybe it’s time Joel gets out of his little FogCreek world and see what the rest of the world has been up to? He’s been on a pedestal way too long.
Sorry, but article and most of comments are just pure envy.
Joel makes money with proprietary compiler. So what. He can.
And you are trying to prove to him that his way is no good. He has results, you did not show yours.
i have probably read each and every one of joels articles, i was a big fan of him.
but things have changed recently, he has slowed down, i don’t find the latest articles as valuable as past articles. i am sure that joel knows about this and he is trying to speculate and remain in the front pages this way
he has the power, and he knows it. he manipulates things even a new programmer would understand to be wrong. he is a great marketing person!
Bart wrote:
“Isn’t writing your own language something you do solely in compiler class? Am sure he has his reasons but I’ll think the cons outweigh the pros.”
I’m sure glad Bart wasn’t the one making the business decision regarding creating Fortran or Lisp, C or C++, C# or Java. Of course, there might have been some benefit to Bart being the business manager for Visual Basic and COBOL but I digress.
The cons of creating a language MAY outweigh the pros but, as the evolution of programming languages has shown, these pros/cons must be assessed against a variety of circumstances such as evolution of software methodology, changing technology, better understanding of human psychology, target market of application, etc.
So, are those of you who are poo-pooing wasabi saying that FogCreek should be maintaining 4 or 5 separate codebases for one product?
Surely not?
Having FogBugz run in multiple languages is a business decision; a decision which brings along a sizable risk. Wasabi is nothing more than an elegant solution to mitigating that risk by replacing the risk of “maintaining N codebases” with “maintaining an in-house language.”
The proof of the pudding is in the eating: Joel is a successful businessman making real money in the real world.
… plus, he entertains me.
Thanks Joel.
I agree with AJ Finch. You guys that are flogging Joel for using Wasabi simply don’t get the point. Maybe it hasn’t been clearly stated, but I understand that Wasabi compiles to the target languages, not that it is actually compiled or interpreted each time a page is called.
What we have here is an example for a domain specific language (DSL) that actually works. (Check out Microsoft’s feeble attempts in this direction, called “Microsoft Domain-Specific Language (DSL) Tools” for a good laugh, or a WTF, if you like). I recommend that you read something about generative programming. For multiple target platforms this is a far better choice than maintaining different codebases.
At our company we maintain the same interface in six different languages. Though the codebase is not large, it’s not fun. Writing a domain specific language parser and code generator is fun, however, so Joel hits two flies with one stroke: keep the bright guys happy, and make the job easier for the juniors. Gosh! I wish I could work for that guy (if it wasn’t for the 5000 miles from here to New York)!
i don’t have time to look at Wasabi carefully and i raise my eyebrows at a suggestion that you can’t do X in an interpreted language or, in this case, Ruby, except maybe for hard real-time things. but i understand why Joel Spolsky and company did Wasabi. to adapt an aphorism popular in a different community, “There’s more than one way to do it.”
in particular, setting aside OO and standardization fever and a lust for the LAMP stack, there is an old and strong school of development which looks at building applications in terms of devising just the right languages for its various parts and then implementing them. this is the school most specifically taught by Waite (ISBN 0134518985) but also practiced by many others, including Burge (ISBN 0201144506). this is the world of macro processing, techniques like the full and half bootstrap, the source of ideas like streams. it a world that list processing languages grew up in, like LISP. it’s viable.
indeed, the only problem with it is that its practioners need to know a lot, both in terms of data structures and analytical techniques. it fell out of popularity partly because it was beyond the skill or training of most people to master. how many can read and understand Burge’s book? or do the problems in Knuth’s second volume?
but if you have an in-house team with superb programming skills, why the heck not? just because the rest of the world doesn’t do things that way? why should they care what other people think?
@Jon Galloway: I repeatedly hear the argument that Vista was delayed because of backwards compatibility constraints. Far from it. The problem was in the other direction: that various teams in user mode were trying to write their new components (e.g. Explorer, Sidebar) on top of Avalon, which was in itself on top of .NET 2.0. These components were never stable enough to know whether a bug was in your code or in your dependencies. Eventually a halt was called to this morass of shifting sands. This isn’t a reflection on the quality of .NET at all - just that trying to develop on top of a developing runtime is practically impossible. Microsoft may use new C++ compilers with new releases of Windows, but they’ve got literally twenty years of working code in there and can revert to an older version if there’s a problem.
In the two years since then, they’ve tried to get what features they can implemented on top of the old Win32 API so they have something to ship.
Vista may have been a five-year project but three of those years were largely wasted. Some components, particularly the kernel, had few dependencies and could be accepted straight into the new source tree, so do have effectively five years of development in them over Windows XP.
I recall reading this from Larry Osterman (http://blogs.msdn.com/larryosterman/) but can’t find a link. Larry mentions the ‘Longhorn reset’ in this article: http://blogs.msdn.com/larryosterman/archive/2005/08/23/455193.aspx. Unfortunately he doesn’t go into details. It’s possible he actually mentioned it on the Channel 9 forums: good luck finding it over there.
I cannot imagine the amount of engineering required to completely throw away Windows and start again, and to do so would be foolish in the extreme. In a much smaller way, throwing away FogBugz would be pretty silly too. BTW, it’s not ‘six-year-old VBScript code’. Some of it would be six years old at the time of making the decision, but you probably couldn’t point to any section and say, ‘that’s six years old.’ Instead, a lot of it would have been edited recently to support new features. It would be six years of working around bugs and implementing new requirements.
If you have code that works for a particular scenario, you keep it. Throwing it away loses you years of development time with no guarantee that you will not incur the same bugs and workarounds that you had to deal with last time.
I have an eight-year-old codebase in Visual Basic 6.0, and it’s starting to hit the limits of scalability (the lack of multithreading in a standalone EXE is starting to hurt). I don’t envision writing a VB6 compiler as I’d hit those same limits - and I don’t have even Joel’s resources. This probably has hit time for a rewrite, as what I can do by extending it with C++ COM components is pretty limited. I’m going to have to be very careful not to introduce more problems than I fix.
Yea guys, stop knocking Wasabi… I’m using it to write my own operating system! I think Microsoft should consider re-writing Vista on top of Wasabi too.
Isn’t writing your own language something you do solely in compiler class? Am sure he has his reasons but I’ll think the cons outweigh the pros. Which is harder: installing .NET on a client’s server or writing and maintaining your own language? Bear in mind that most servers aren’t bought solely to run FogBugz. Chances are other programs running on those server require some form of runtime (java, .NET, php etc).
Joel has this “do what I say, not what I do” thing going on. He has for years, too.
I remember being astonished when I found out Fog Creek wrote their own installer from scratch for FogBugz. They don’t use InstallShield or Wyse or any of those tools. This is kind of like writing your own language; oh, wait, I guess they did that, too.
There is no way this makes sense, it violates Joel’s own “do your core competency and outsource everything else” philosophy, at least as stated in his posts.
My theory is that when people get stuck, they look for “easy” things to work on, and writing installers or langauge compilers is easy, compared to you know stuff like writing actually shipping code for customers.
Ole
P.S. I love Joel’s writings. Do what he says, not we does!
There is no way this makes sense, it violates Joel’s own “do your core competency and outsource everything else” philosophy, at least as stated in his posts.
Exactly. And Joel is such a brilliant, persuasive writer he can actually convince you writing their own installer/language was a good idea. It’s scary, actually.
There is at least one thing that makes sense to me:
So it’s open source, but it’s also a proprietary tie-in to a particular platform.
This whole “Joel’s Gone Crazy” thing bothers me less than it did when I first read it a couple of days ago. I think what bothered me the most was how Joel put the Wasabi revelation at the bottom of his discourse about how to choose a enterprise platform stack. That made it stick out with the big “WTF”.
What bothers me more are his complaints about Ruby being slow in regards to “doing millions of calculations to display a single chart on a single web page”. It’s actually pretty easy to develop a module in C for Ruby and load it at runtime, so that the call “MyModule.generate_table(some_data)” will look up and call a C function that can loop across the data or do its own MySQL lookups or whatever. That function can be as fast as any C function can be. It’s part of the “optimize later” strategy, and you know it’s always available.
It’s my opinion that there are two types of languages: Ones in which the machine is efficient (assembly, C, DSP-centric languages), and ones in which the developer is efficient (any dynamic language). The good news is that you don’t have to pick only one. For a project I’m working on, we have about half the code in C and about half in Lua. All of the computation and system device interface code (libraries) is done in C (some of it automatically generated from text files) and all of the user interface states and scripting is done in Lua. It works really well.
it does seem to contradict earlier comments and assertions Joel has made. Maybe he fell in love with the intern who wrote Wasabi and let that affect his judgement…? somehow I don’t think the best programmers from the best schools want to work in vbscript. (he’s always big on hiring the best and brightest) vbscript is for dummies like me 
Owen’s comment is somewhat interesting. It says “I don’t think the best programmers … want to work in vbscript”.
However, the best programmers know that writing code to communicate with a computer is only a very small part of their job. Steve McConnell, in Code Complete at page 764, writes “A guru … recognizes that programming is only 15 percent communicating with the computer, that it’s 85 percent communicating with people”. As such, the programming language is not as important as the language, structure and design of the application. Programmers who endlessly bicker about what language is best and which languages they will/won’t work in have very likely failed to make the transtion from what Steve McConnell calls the Intermediate and Specialist levels to the Guru level (i.e., the best programmers).
Maybe Joel’s first big mistake was simply not calling Wasabi what it is: a domain specific language (or a language translator). Apparently customers never see the Wasabi language. They only see something they are familiar with.
(Joel’s second big mistake was writing a muddle of a criticism against Ruby.)
Everyone seems to agree that Joel is a genius of a writer. Just to play devil’s advocate, it could be argued that this whole mess is the result of confusing writing. If he had been more clear about what Wasabi is and what role it plays, all of this might have played out differently.