Web Apps and Language Wars
I wasn’t planning on posting about either web apps or linking to Joel Spolsky again, but this language wars post is just too interesting to pass up. Besides, a jillion people have already commented on this, so what’s a jillion and one?
Spolsky is riffing on what language or platform you should use for an enterprise web project. He makes a few points (note, I’m paraphrasing him here – these are his points, not mine):
-
There are 3 1/2 platforms that are proven to work in the enterprise web app space (Java, C#, PHP, and maybe Python.
-
Within that group, there’s no difference large enough to offset expertise, so pick the one that you know the best.
-
Rails is not part of that group. Even though it’s fun.
I suspect you know which one of those three points has gotten the most attention. Obviously the Rails people are ticked off, which I think is a combination of Spolsky taking his point too far, and Rails partisans taking his point even farther.
Look, I love Rails as much as a person can love a framework. I wish I had been smart enough to put all the pieces together myself (another post for another time…). My Rails experience has been uniformly positive. Nevertheless, if I wanted to pitch Rails for a mission-critical enterprise application, I would expect to have to justify the choice. Using Rails is still a risk, relative to the others, it’s still newer, people are still trying to work out optimal deployment, it still doesn’t have the library support the others have. Where I would differ from what Spolsky is saying is that I think it might be a justifiable risk even in a mission-critical enterprise application.
Scaling and library support is not the only source of risk. There’s also the risk that your code will get bogged down in a huge ball of intertangled display and logic code (PHP). Or the risk that your developer time will be slowed down enough that it delays deployment (Java). Or the risk of deploying in a system that is owned by Microsoft (guess…). Choosing one of the “nobody ever got fired for choosing X” languages is a safer choice. Which doesn’t always make it the best choice.
(And yes, I know that Spolsky ends his essay by mentioning that one of his apps is written in a custom in-house version of VBScript. Red herring. He’s not saying that Java, C#, and PHP are the only languages to use ever, just that they are the only languages that currently have the ecological support to be guaranteed safe in a “death before failure” scenario.)
I’d argue the following corollary: I agree that, all else being equal, expertise trumps any difference between these platforms. That’s a little circular, of course, because how will you get experience without using a tool? (I know about apprenticeship as a junior member on a larger project, but it’s not always feasible.) Almost every project or team spins off low-level applications – bug trackers, vacation trackers, internal chat rooms. Things that are not high-priority, but are still useful. So, when putting those together, I think it’s a good idea to range far and wide and try new things that might pay off in a future project (I almost wrote that you “have the right, no, the duty” to do that, but I thought that might be a little over the top). Me, I’m going to try out Python/Django next chance I get…