One of the great things about sitting in traffic is you get to ponder various things. Recently I was contemplating the ongoing debate about REST vs SOA. Last week I was involved in discussions on C++ vs Java. Last night I stumbled across some debates on Django vs Rails. It occurred to me that software engineers are unique within the technical world. Rather than rejoicing in a rich toolbox, we argue over its contents, hoping to discard all but the smallest possible set.
One of my hobbies is British cars. We have two in our garage which means that either I learn to work on them or go broke paying mechanics. So, I participate on discussion lists related to them. Occasionally somebody will suggest a unique application of a tool to address a difficult issue. If others have found alternate approaches, they'll share those ideas, usually involving a different tool. I have never once, in more than a decade of participating in these discussions, seen an argument erupt over whether one tool or the other was the singular correct approach. Sure, if the tool was completely inappropriate and might actually result in damage to a component, there is a discussion. But as a whole, mechanics don't argue whether the open end or boxed end of a wrench is the single correct end and should be used to the exclusion of all other wrenches or sockets in existence.
I also have several friends running contracting companies. I have spent time around job sites. I can promise you that you'll find circular saws, chop saws, and table saws. Is there overlap in functionality and potential application of these saws? Absolutely. Why have all three then? Well, because each is particularly good for certain types of cutting chores and less optimal for others. Contractors, like mechanics, want a broad set of tools available so they can have the optimal tool for each task.
Why then do we, as software engineers, have to work so hard to reduce our toolbox to the ultimate tool? There is this tendency to look for the Swiss Army language with supporting framework that will be the optimal solution for every problem in the world. The simple reality is that such a language and framework can never be created. Why? Well, engineering is always about compromise and the compromises are intended to optimize the solution along certain paths. If your problems lie along that path, then the tool will be perfect. If not, well, you have a sub-optimal tool.
I'm ecstatic to have a rich set of languages and frameworks available in my architectural toolbox. The shear breadth of the problems that we face everyday makes it important to have options available. Understanding these tools and there applicability to any given problem should be the job of architects. There are plenty of hard problems that need attention. Spending energy trying to denigrate or eliminate viable tools is pointless.