Hi Steffen, 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. Obviously this is more expensive and more effort than having to maintain just one language.
I'm not trying to pick a fight with Parrot here, in fact I think the best way to put it is more along the lines that Perl 5/6, on Parrot, will compile down to a *language independent* format. At least I think that's so. Someone correct me here, especially as that's what I think Steffen was saying. So does that mean I can write a module in Perl 6, deliver it to Mr. Customer as byte-code. Then Mr. Customer can "decompile"(?) it into Python (or JavaScript, or C, etc), edit it, and then compile it back into working byte-code again? 'Cause if THAT were true then it would be revolutionary and businesses would be fighting to get their hands on it (once it was stable and proven). Much more inviting than saying Parrot will allow lots of different languages to start sprouting up in unexpected areas of the company's code base. --michael On 25/05/06, Steffen Schwigon <[EMAIL PROTECTED]> wrote:
"Michael Mathews" <[EMAIL PROTECTED]> writes: > So my question to the list is, in simple terms even an IT manager > could grasp, explain what problems Perl 5 has that Perl 6 fixes, > such that they would want to undergo the pain of ever switching. From a Perl point of view: there should be no pain. At least that's a stated goal. From a manager point of view: it's as use(ful|less) as ever to decide for a language independently of the problem to solve. If Perl5 does the job, stick with it. If Perl6 helps you somewhere, use it. If Visual Basic solves your problem because it's already built into the problem, just use it. Perl5 is already gluey enough to not force you into a decicion for *the only one* technology. Perl6 shouldn't change that. Steffen -- Steffen Schwigon <[EMAIL PROTECTED]> Dresden Perl Mongers <http://dresden-pm.org/>
