"Michael Mathews" <[EMAIL PROTECTED]> writes: > I'm glad you made that point. If I understand your statement, it's a > common "gain" cited by Perl 6 (actually Parrot) advocates: you can mix > languages. But a point I was trying to make was that while this is fun > for us developers, managers hate it, with very good reason. Having one > crucial part of a system written in, say Python, when the other 98%is > in Perl, is actually considered a Bad Thing. It means having to have > experts in two languages around at all times should anything go wrong.
I don't think it's about hacking a project with two or more languages from scratch. I think it's about using strong libraries that emerged in other language worlds. In the Perl world it is common practice to find a wrapper on CPAN that makes a foreign language module (mostly C) usable. It's that common because of to the "gluey" nature of Perl and the mostly easy way to use C code. If that practice would expand to not mostly C libs, as it's usual today, but practically to a general use of much more libs from the outside world, that would be a Good Thing, because a lot of problems would be solved not just "once per language" but even really "once per universe". And within the Perl5/Perl6 world I think we don't even have to set all our money and propaganda on Parrot. Look at the Pugs project and read Audreys blogs to see how they couple the Perl5 and Perl6 world with a lot more tricks than only by bytecoding to Parrot. They do it right now and in both directions. Not always without hazzle, but it's just the beginning. Summa summarum: So I don't think it's about hiring the same number of language experts as the number of different languages you use. I think it's about making programming more borderless, making the use of libraries similar to todays typical use of whole programs, independently of the language it's written in. GreetinX Steffen -- Steffen Schwigon <[EMAIL PROTECTED]> Dresden Perl Mongers <http://dresden-pm.org/>
