I totally agree with their being a "right tool for the person/team". Bringing a new language to an existing codebase, especially one where the developers are unfamiliar with it, is hard. It will often be the wrong decision and this does have implications for language advocacy.

However... :-)

I can't prove that I'm right about this, but one point in my favor is the relative absence of multi-(high)-language applications. While we often see Java/Perl/Python/VB mixed with C for speed-critical components, applications with equal mixes of Java and Perl, for example, are almost unheard of. Similarly, I haven't seen many projects which equally mix Perl and Python, or VB and Java.

I think one of the main reasons for this is the tools. There isn't any support for it in most development environments.

I worked for several years both coding with, and helping develop, a programming environment called Poplog. It had a single IDE that allowed you to develop in Pop-11 (which you won't have heard of :-), Common LISP, ML and Prolog. All the languages compiled down to the same stack based VM, so it was really easy to write code in multiple languages - and many Poplog users did.

Because they were all running on the same VM it was trivial for Prolog code to call Lisp code that called Prolog code again, that then called some Pop-11 code, etc.

The ability to merge languages like this is a very different experience from calling an external library in another language.

That said, want to use Bob's Prolog expert system shell with your Common Lisp stats package, with a UI developed using Pop-11's PropSheet library - bish bosh done. Darn handy.

I don't agree that "basically all high-level languages are equivalent". I really do think that some languages are better for some tasks. Text processing is easier in Perl. Multi-platform UIs are easier in Java. Writing code that manipulates code is easier in Scheme... and so on. Some of this is because of the available libraries rather than fundamental language differences - but that doesn't make it any less true.

I don't want to write 100 lines of perl when I could write 10 lines of Prolog (I still miss Prolog occasionally :-). Equally, I don't want to write 100 lines of Prolog where I could write 10 lines of Perl.

One of the things I'm finding interesting in the development of Parrot is that you're seeing lots of languages other than Perl being implemented. I can see support for multiple languages being a natural extension of Perl's TMTOWTDI attitude.

Coding in multiple languages is hard. Finding a development team that is comfortable with developing in multiple languages is hard. Hopefully this will not be true forever and people can start taking advantage of the best points in all languages.

(I'm about to digress and have a little rant... people interested in the original topic please leave now. :-)

Personally, I find a lot of language advocacy disturbing. I find a great deal of it consisting of inaccurate abuse rather than reasoned argument.

I've lost track of the languages I've learned in my career as a programmer. Every one (even BASIC :-) has made me a better developer. Each has brought some new angle or perspective on how I look at problems. Each one has been slightly better at some task or another.

One of the things I look for when hiring coders is the number of languages they've coded in. In my experience, the more languages the better. Instead of seeing how to solve a problem in Perl (or C++, or whatever) - they look at how to solve the problem.

Perl's a great language and I love it dearly. I do the majority of my professional development work in Perl. But it isn't the best thing for every task in every situation. Neither is Java. Neither is C++. There is no silver bullet.

I find a lot of new developers coming out of school or university only knowing language X (where X is usually one of Java or C++). They see everything in terms of that language. Every problem is interpreted through that languages advantages and limitations. I love introducing C++ only coders to CLOS or Eiffle and see the rapid expansion of horizons pop their eardrums :-)

Anyway... I've started mixing metaphors so I'll should probably stop now... We now return you to your original programming.