My personal opinion is that a project can be language agnostic. You can build in whatever you want. It doesn't matter if you build your app in php, ruby, python, asp or whatever, if you're a good coder you will produce good secure code, if you suck, so will your code.
So build in whatever you're most comfortable with and don't pick a language because of a superficial reason.
Maybe the best answer. I would just add, that if you need to integrate with a special system like an already existing business application, just be sure to have a supported set of libraries to access it from within your web application. This is the only constraint that would make me discriminate a language against another outside of the very good points of Tam.
Isn't this the opposite of "pick the right tool for the job"? Building with whatever you're most comfortable seems to be a superficial reason. Different platforms/languages have real diversity in their strengths and weaknesses.
You raise a valid point if you're putting up a shelf. But if you're programming then you'll be at a disadvantage if you're not familiar with the tools at hand. Even a designer is going to suffer if they're made to use the Gimp when they're used to Photoshop, not because Gimp is or isn't a good tool but because the interaction is different.
Switching from Lightroom to Aperture I've noticed substantial differences in my photography, and I'm not a very good photographer. I'm considering switching back to Lightroom - I'm sure Aperture's great, but the learning curve is harder than switching from Vim to Emacs.
I agree with this to a point. You should produce code in whatever language you are most proficient/comfortable with, pending that language is suitable for the domain in which you are producing code in. I wouldn't want to try to produce a web application in Assembly.NET, nor would I want to develop a low level component in Ruby. Depending on the domain, language becomes a bigger issue, which may result in you not having the ability to be language agnostic. But, in the overall sense, I do agree with what you're saying.
There still is the question of how much time you're willing to spend to hunt down bugs in the interpreter/standard library/framework or to work around certain idiosyncracies that once upon a time might have looked like a cool idea. Will a "good coder" tolerate more or less such wtf moments?