Front page | perl.perl6.users |
Postings from May 2006
Fwd: 3 Good Reasons...
From: Michael Mathews
May 25, 2006 15:28
Fwd: 3 Good Reasons...
Message ID: email@example.com
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
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.
On 25/05/06, Steffen Schwigon <firstname.lastname@example.org> wrote:
> "Michael Mathews" <email@example.com> 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 Schwigon <firstname.lastname@example.org>
> Dresden Perl Mongers <http://dresden-pm.org/>