This idea that a software engineer picks a language as his "favourite" and becomes a "Ruby developer" or a "JavaScript developer" ever since is completely misguided, and I'm sad to see it cherished further in this article. Languages are tools, and tools should be picked depending on the project: its application domain, performance requirements, availability of libraries for important subproblems that have been identi…
Obviously, if the project is far outside the sweet spot of a given programmer's favorite language, it's worth it to learn a different one. The larger the project, the more often this is true. If for example, a Java specialist wanted to build a webapp, it would likely be worth it to invest the effort to learn how to do so with JavaScript instead of sticking to the familiar GWT. But for a smallish text manipulation task, it's just not worth it for an expert user of Ruby (a pretty good text manipulation language) to learn Perl (a language really designed for text manipulation).
The sweet spot, in my opinion is to work at getting very good at one language per major domain area and change focus only for large projects, for projects far from the sweet spot of any already known languages or for fun.