While I agree with this statement, that technique is more important than superficial or trivial language decisions, I think there is a second level of reasoning that needs to be brought into play here.
Once you know several techniques and several languages, and have started to get a skill at identifying the core bits of a project, the process (or series of questions to answer) becomes:
- what technique will effectively handle to core problems?
- What languages make this technique simple to implement?
and then the real kicker, which in a way comes full circle to the original naive analysis:
- in the best language for $technique, are there any problems with secondary and ancillary problems associated with it? (e.g. i have to do this really fast lookup table of simple operations, C would be great for this, except that the data is irregular and involves a lot of string parsing C sucks at that..., or the central problem here is just a big fold, i'll use Haskell, but it involves a lot of tricky memory optimization to be fast enough...)
Out of this of course arises a meta-technique of learning to partition problems into stages in different languages, which of course has its own problems.