Joel Spolsky run over by train. Pictures at 11.
01. Sep, 2006 
17 Comments
When I read Joel Spolsky’s Language Wars I didn’t know what to think of it. Was he serious? Was he looking for flame bait? Or did he simply not have a clue?
DHH is not one to back down from a challenge like this:
So Joel and friends invented their own language, which has to reasonably compile to three and a half different ones. Yes, they’re building their Serious Business Stuff application on a 1-off, closed language. So please do as I say, not as I do, dammit. And pick something mainstream and “safe”.
I swear I couldn’t make this stuff up even if I tried. Joel, you’re my new hero of irony. And as soon as you start selling those t-shirts with “Serious Business Stuff”, I got green ready to flow. Short of that, I’d take a red teddy bear with the embroidering “Someone is Going to Get Fired”.
I have played with Rails and find it fun, but it is very clear that Rails is not ready for corporate development. The more DHH whines about it is, the more I worry that it might never make it.
A lot of people have focused on the technical issues: lack of internationalization/unicode, performance questions, poor legacy database support, deployment pain, whatever.
What I worry about more than the technology is the lack of a maturity amongst the Rails team. I don’t think they realize that the goal with most apps isn’t to just have random fun. The goal is to have apps that work well and run a long time supporting business needs.
Every minute an application I build is down causes a loss of revenue to my company. In fact, it causes a lot of money to be lost, and is just unacceptable.
It is not cool to have to keep changing code and redeploying every few weeks to catch up to the latest breaking changes Rails makes. That DHH is out boasting about all the APIs he is planning to remove with the next release (a complete list which isn’t documented anywhere btw), while claiming Rails is ready for corporate development is just nonesense. That the top Rails books and even the Rails Wiki itself has samples that work today but won’t in the future is just terrible. The bottom line is that any code you write for Rails right now has a limited timespan and will have to change probably several times over the next year.
Rails fanatics will tell you to just freeze to a specific version of Rails and not worry. But…oh wait….the Rails team doesn’t guarentee security patches for older versions of the framework. So if a security hole is found (like the one a few weeks ago) an old application that is frozen is well and truly screwed. It might be down *days* while trying to upgrade it to a newer version of Rails. Do you guys not realize that having an order system or sales management app be down multiple days could kill some small companies?
There is a difference between coding for fun, and coding for business. It is really worrying that a lot of people don’t understand the requirements of the later.
BTW — there is some irony that your blog comment system was returning application errors and I had to try three times to post the above comment.
I for one consider “random fun” to be one of the most precious aspects of a software development environment. If I cannot enjoy myself programming, my productivity drops drastically.
Re: Deprecation. In the next version, 1.2, we’re going to MARK all the pieces of API that we’ll be removing in version 2.0. I think that’s pretty much standard policy amongst most development groups. Major revision numbers are were you get rid of deprecations. Otherwise, why ever deprecate anything, if you’re not going to remove it?
Re: Security. Within 24 hours of the one major security issue we’ve had, there were patches available for every single released version of Rails affected. But yes, eventually, some versions will be end-of-lifed. Just like you’ll be hard-pressed to get the Apache team to release security updates for Apache 1.2. That’s the normal life cycle of most open source software.
Most fundamentally, I strongly oppose the false dichotomy of either you program for fun or you program for business. That split is not only artificial, but seems more like a self-serving fairy tale you can tell yourself to why your current environment is making you unhappy. Well, I’m doing Serious Business Stuff, so it has to suck. That’s just the way the world spins. Bullocks.
Seems the Ruby zealots are shaping up to become even worse then their Python counterparts.
A couple of points: the Unicode issue isn’t one that the Rails team needs to address – it’s Ruby. Now these issues can / will be eliminated via one of three possible routes: Ruby on JVM, Ruby on CLR or Ruby 2.0. The question is one of who will ship first, not whether it will happen.
So if you’re blocked by Unicode issues, will you’ll either need to workaround them or use a different framework *today*. This is clearly not going to be the case forever.
On the other point, one thing to get used to as you move into the open source world is that you have the source code. So even if Joel does some ‘fire and motion’ on the entire Rails core team you’ll still have the ability to patch security holes yourself. This isn’t the case when Windows / VB / whatever is end-of-lifed (well you could do it there too, but your name would have to be Mark Russinovich and he now has source code access).
Now that being said, it’s also important to have a roadmap once you’ve shipped software that people have taken dependencies on. I don’t track Rails all that closely, but given DHH’s comments here, they certainly seem to be doing reasonable things.
Regarding the lack of responsiveness around here – I get spammed *a lot*. There seems to be an architectural flaw in typo where the calls to Askimet seem to be happening synchronously. So when the spammers blast me (and I’m running on a shared server here) you’ll timeout Rails / typo.
I’ve been meaning to look into this, but RubyCLR pretty well soaks up all of my cycles these days.
I read the Wasabi thing as a joke.
It isn’t?
Also, things occur to me after I press Submit all the time.
RoR currently has tons of hype. That sort of hype inevitably leads to backlash. Instead of circling the wagons at the first sign of dissent and shouting down those with criticisms (whether they’re valid or not), it might be good to more publically acknowledge where things are weak and need to be improved.
We (meaning people mostly on the outside looking in) hear a lot about how Rails/Ruby can do absolutely everything, which we all know is false. If the presentation were a bit more balanced (here is what Ruby/Rails is fantastic at, here is why we like it, here is what sucks about it now and how we’re going to change it), maybe the reactions wouldn’t be so polar.
There are a couple of ways to see past the hype. The best way is to take a good long look at it yourself by building something in your spare time.
However, most people don’t have the spare cycles to do this, so the next best thing is to look at the credentials of the people that are doing the hyping. There are a lot of folks that really love Ruby (and some subset of those folks are doing things with Rails). So take a look at what Martin Fowler, Dave Thomas, James Duncan Davidson, Tim Bray, Don Box are saying about Ruby. There’s not a lot of hype there and these are guys with long and distinguished careers in software on different platforms.
One anecdote from some friends in the Java world is that 75% of the speakers on the NFJS Java conference circuit are making some percentage of their incomes off of Ruby (and most of that I’m pretty sure is Rails related work). Now that’s a pretty compelling endorsement if you ask me.
That approach worked for me and is why I’m looking into Ruby in the first place. I think it was Don Box that pushed me over the edge. What was frustrating was that I knew there had to be drawbacks (because there always are), but it was difficult to find them documented somewhere. To be fair, Microsoft doesn’t have a Why C# Sucks page on their website either.
I think it’s just zealotry in general that gets to me. I’m not worried so much about my ability to cut through the hype, rather that the higher-up decision makers will only hear the extremes of opinion (and not know who Don Box is or why they should care) and write off the language as the latest buzz. I guess if the hype sustains itself for awhile then it transcends from hype to Common Wisdom or something and you’ve won.
I’m certain the Wasabi thing was a gag.
That said, Rails is ok. But I hesitate to call it great, yet. I like the full stack concept (Ruby throughout) and the way it follows the Principle of Least Surprise. What I’m not keen on is the sheer number of files that are produced, and the directory structure. Without exaggeration, I find that some sessions I spend searching around my project for stuff, more than I spend writing code.
That said, it does some fairly impressive things with small amounts of code. Perhaps a nice Rails development environment would help.
Rob, you may want to take a look at a keynote presentation that I’ve been giving about dynamic languages recently – http://www.iunknown.com/articles/2006/05/25/my-vs-live-keynote-on-the-future-of-programming-languages-is-now-live.
It’s a nice way of talking about the benefits of dynamic languages from a very high level without offending too many people. I gave a version of that talk to the CLR team at Microsoft and they seemed to get it (most of the folks in the room weren’t writing any code in Ruby).
The higher-ups at bigger companies (the CxO crowd) will wait around until Gartner or Jupiter writes up some Rails enterprise success stories. I don’t think these are very far away now. I know that Thoughtworks has been doing some great work in this area, and they’re the right kind of consulting company to write up for the likes of a Gartner.
Chris, +1 on the many little files problem.
I’m in the middle of doing a religious conversion from emacs to vim, and one thing that I’ve started doing a lot of in vim is using ctags to enable hyperlink navigation through source code. So I’m using that where I used to use grep, but I still have to use grep to find some method in a different file by name.
Regarding Wasabi as a gag – if it were it would be real nice if Joel would own up to it so that the endless speculation on whether it was a gag would stop
Thanks for the link. I caught your talk at TechEd with the IronPython folks. I think I lamented C#s lack of mixins and some way to hook into the method dispatching like method_missing to you afterwords, as those were the neat bits of Ruby I had played with so far.
The year before that I went to a few great dynamic language sessions at the PDC when IronPython was churning away and Eric Meijer did a pretty good job evangelizing then, too. .NET pays my bills at the moment, so I’m happy to see that Microsoft wants the CLR to work for dynamic languages as well (and that Anders is pulling functional language elements into C# as well).
Good to know about the Thoughtworks stuff. Playing with Ruby is fun so far, but getting paid for it in a consulting context would be great.
Some folk think Wasabi is a fiction … and other folk wonder if Joel is clueless.
*shakes head*
Joel says Wasabi is Real http://joelonsoftware.com/items/2006/09/01b.html
A nice Rails development environment… there’s a project building just that based on Eclipse: RadRails http:/radrails.org/ . It’s young yet, but fairly functional. Syntax guided editors for all the rails file types (rb, rhtml, rjs, css, yaml), helpers for rake tasks, generators, etc. Hot keys to jump around related objects/files, Templates for common rails code snippets.
Mature == Learnt from failure
I would say Rails probablly hasn’t failed enough in the “real world” of enterprise apps.
However on an intuitive level it seems obvious Rails (or something rails like) is going to be the most productive way to do enterprise systems. But then, lots of people didnt seem to intuitively get why extreme programming was a productive way of doing software.
evoloutionarly speaking, Rails may not be a “safe” choice, in that staying with the “pack” is your best bet of survival, but sometimes, just sometimes, the ones who break from the pack are genetically superior
survival of the fittest will sort things out in good time