I bookmarked Derek Sivers' recent blog post giving 7 reasons he switched back to PHP from Rails. Turns out I wasn't alone: 1,050 other people on del.icio.us bookmarked it as well. Since then people have been getting all worked up about it on Ruby discussion lists. Obviously, if over a thousand people bookmark something, and spend time discussing it, then people think it's a big deal. But people are wrong. The post didn't really even have 7 reasons. It just had one:
OUR ENTIRE COMPANY’S STUFF WAS IN PHP: DON’T UNDERESTIMATE INTEGRATION
That's about it. If you're looking for all killer, no filler, Sivers' article won't deliver. There's one important point - integration is hard - and one cool insight - "languages are like girlfriends, they're better because you are better" - and there's also a whole bunch of extra words.
Last year Chad Fowler wrote about the Big Rewrite and why it always fails.
You’ve seen the videos, the weblog posts and the hype, and you’ve decided you’re going to re-implement your product in Rails (or Java, or .NET, or Erlang, etc.).
Beware. This is a longer, harder, more failure-prone path than you expect.
Throughout my career in software development, I’ve been involved in Big Rewrite after Big Rewrite...In many cases, these Big Rewrite projects have resulted in unhappy customers, political battles, missed deadlines, and sometimes complete failure to deliver. In all cases, the projects were considerably harder than the projects’ initiators ever thought they would be.
This is not a technology problem. It’s not at all Rails-specific, but being in the limelight these days, Rails implementations are both very likely to happen and very risky right now.
This is exactly what happened to Sivers. He attempted a big rewrite in Rails and later abandoned it for an incremental rewrite in PHP. The Big Rewrite doesn't work. Incremental rewrites do work. But that doesn't say anything about Rails or PHP. You can fail with Rails and succeed with PHP for reasons that have nothing to do with either language.
For some reason, few people in programming study what other programmers have done before, and so, given that the majority of us don't study history, the majority of us are doomed to repeat it. That's fine. If you don't want to study history, go ahead and repeat it. But some of us do study the history of what we do, and some of us have already learned these lessons the hard way.
Personally, I think this failure to study history is a serious shortcoming.
When you think about the reams of money companies go through every time an inexperienced programmer or manager learns this lesson the hard way, and you put an actual price tag on that experience, and then you compare it with the price of a freaking book, you kind of have to wonder what's going on with people in our industry.
Anyway. For what it's worth, the next few days are going to be a good time to write code (or go to conferences!) but a terrible time to read e-mail lists and blogs. There's going to be a lot of discussion about what Sivers' post "means." I'm as guilty as anyone else of responding to the hot topic of the day, but if I see any more discussion of this post, I'm just going to read some programming history on Wikipedia (or even - gasp! - write some code). My suggestion: the moral of the story is that many programmers have a shallow and irrelevant fixation on languages, and don't spend nearly enough time learning the history of what we do.
Update: Raganwald noticed this too.