Slashdot videos: Now with more Slashdot!
We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).
Yes, there are times when the project gets sub-optimized by being constrained language-wise. Developers will grumble (and I am a senior development resource, BTW), but overall, the cost is less to enforce some standardization. Why?
Cross training/support. The fewer languages, the more bodies we have on staff that know it.
Integration. Not everything can be a web service. Our business users hate us telling them that we need to rewrite that chunk of code because it is in Language A and the rest of the project is in Language B
Development Machine stability: Compilers, IDEs, runtimes, etc., all have to pass through a rigorous testing matrix before they can be loaded on Development machines. Cringe if you want, but SOX and other regulations make those things necessary. Thus, more languages means more money tied to testing and certifying the components on a development box
Coding standards: The fewer languages, the fewer times we have to sanction a team to author standard for that language.
As a developer, I find the "languages as hand-tools" analogy severely lacking. Possibly, treating them like powertools is better. Once I select my Dewalt cordless tools, I am locked into a battery option, saw blades, etc. Some stuff can be bought generically, but I'm not going to go out and buy a Wilwaukee set of cordless tools just because their saw option does a better job on miter cuts. I will figure out a way to make good miters with my Dewalt. If I find myself making miters all day, I might consider buying just the Milwaukee saw, but I know I'll be forking over more bucks for extra chargers, batteries, blades, etc. I will not do that lightly.
I applaud developers who can pick up languages easily and are fluent in many. That said, language prowess does not give the developer license to create a programming Tower of Babel. If a developer can't show that kind of restraint, the company is no longer a good fit for him/her.
In the end, I think 1 is too few languages, but I think > 4 is too many for a large firm. Same goes for editors, compilers, etc. Of course, each company has to weigh the risks against the benefits. I can see a cross-platform developer needing many more compiler options, and there are no doubt firms where performance cannot ever be sub-optimized, so my comments are moot. However, for those who live in a data-processing land where I exist, there is little to gain from switching languages like a playboy switches partners.