Wasting Cycles
In a recent “exchange” about the relative merits of computer languages between the creator of Ruby on Rails,
David Heinemeier Hansson (DHH) and
Joel Spolsky (Joel), DHH cited trying to save "developer cycles" over CPU cycles as one of his guiding principles. Now, leaving behind the details of that particular debate and the people involved, I'm going to steal his quote for use in my argument.
I agree with this sentiment, and I think it should be applied to many of the unending debates over language supremacy. Ultimately, the debate over which language is better or best is about as useful as a debate over which color is best. By that I mean that it is an argument so arbitrary as to be meaningless.
Programming languages don't exist in a vacuum. Ruby, through Rails, may be great for rapid development of websites, but are you going to use it to create a high performance first-person shooter engine? For those of us in the .NET world, would you give up WinForms for faster executing C if you were creating a desktop application? To say that LISP is great because you can write you our own domain specific language for any problem is perhaps true, but if you are on a tight timeline to deliver a web app into an organization that is all J2EE, would you still use it?
Simply put, the idea that any one language is somehow inherently better for any problem than any other language is a simplification that ignores the realities of what programmers do, solve real problems. This simplification does have some benefits; you can really specialize in the “best” language; you can feel confident that you have the right tool for any situation.
However, it has some negatives as well; on a professional level, you close off opportunities for yourself because you'll only use your language. On a personal development level you isolate yourself and lose out on the insights that come from seeing how other languages do things. Finally, you might find yourself spending a lot of your free time defending the best language and assaulting all of the rest. These negatives make an abstract debate over language a philosophical luxury, interesting to observe, but not really enriching.
So red may be a good color to make a warning sign because our culture understands red to mean danger and khaki may be a nice color to make clothes out of so that it is easier not to clash at work, but that doesn't make red or khaki the best color.
To switch metaphors up a little bit, people naturally like to see a winner after a competition. In both football and baseball the team that scores the most wins. However, would you suit up the Yankees and have them play in the NFL or have the Colts wide receivers try to turn a crucial double play? Of course not. Kind of fun to think about, but won't help you win football or baseball games.
In the end the point I'm making is not a new one. Passionate people will have debates over these things for as long as they are passionate. Debate can spark competition and innovation. For example, a debate over the best way to rapidly develop web applications can lead to an innovative new framework for one language and subsequent reactive actions from others. However, a debate without this kind of clear context just leads to more debate, and on and on. Kind of like an out of control recursive method, gradually wasting more and more CPU cycles.