An example I can think of straight off is I often find myself writing intermediate Perl scripts to munge text into a format more palatable to Java (XML works, because the Java XML APIs are quite nice). Personally, I find parsing most text formats with Perl to be much cleaner and easier than in Java. (Yes, I'm aware Java now has official regex support, but the quoting required is just nasty.)

My point wasn't that all high-level languages are exactly the same. All I was saying is that other considerations besides the strengths of the language will often be more important. Again, if you are in a 100% Java shop and you have to munge some text, writing a Perl script, while easier if you already know Perl, may still not be the optimal solution for your team as a whole.

But yes, I think there's little question that each high-level language has its own strengths and weaknesses. And while the differences are significant when abstractly comparing languages, they become less significant in the face other factors.

I agree with you that, in most cases, bringing a language into a project established in another language is a bad idea. I do not, however, think that makes every high-level language exactly the same. Furthermore, I do not think that makes the currently selected language *always* "The Right Tool For The Job." Sure, sometimes it is a much better decision to use the "wrong" tool for the job... but that doesn't magically make it a better tool.

I guess the main difference boils down to how we're interpreting "The Right Tool For The Job." You are taking the more pragmatic approach, which I think is the right thing to do most of the time. I still think there's value in paying attention to the more abstract component, though. And that's what I think this whole Right Tool business is talking about.

In any case, I think we've flogged this freshly dead horse long enough. I guess I'll agree to accept your wrongful interpretation of this too-often used term. :)