Re: Hockey Sticks

[tobyink]

As much as I like Perl 6, all its implementations are right now missing the one killer feature that could drive adoption. And I don't mean heredocs in Rakudo.

Imagine I wanted to port some of my Perl 5 modules to Perl 6. What exactly would that entail? A more or less line-by-line translation of a module might take, say, 30 seconds per line of code, so maybe 2 or 3 hours for a smallish module.

And yay, I'm done. Or actually, maybe I've hardly begun because the first few lines of my script were:

use LWP::UserAgent;
use RDF::Trine;
use XML::LibXML;

... d'oh! Now I've got another few months ahead of me in my porting exercise.

This is a major problem for people hoping to use Perl 6 for actual work. People say that CPAN is the best feature of Perl. If Perl 6 doesn't have CPAN, then no matter what other features it does have, it's missing the best feature of Perl.

I'm not saying that Perl 6 needs to reimplement all of Perl 5. It just needs to embed libperl so that Perl 6 code can load and use Perl 5 modules. While not trivial, this seems achievable.

I think perhaps many of the Perl 6 developers are afraid to implement such a thing, because if Perl 6 can run Perl 5 code, people have less of an incentive to port their Perl 5 code to Perl 6. But I disagree - I think that the burden of having to port not only your own code, but any underlying libraries you use acts as a strong disincentive right now.

[raiph]

Larry has planned use of Perl 5 and CPAN from within Perl 6 from the start. I am confident several approaches will get implemented, once the right pieces are in place. I agree it will make a huge difference.

One approach is embedding the usual perl interpreter via libperl.

jnthn's blizkost enables Perl 5 code to be executed within Parrot (and hence using Rakudo on Parrot). I think jnthn recently said that blizkost is currently broken and that he hopes to fix it in the next few weeks.

Aiui, blizkost currently does very little, just eval'ing a single line of perl5 code, and not even making use of the result. I think that developing it toward supporting Perl 5 modules was blocked on other progress, in particular implementing native 6model. Maybe it'll move forward this year.

Update August, 2014: jnthn implemented native 6model in 2012/2013 -- in a brand new VM MoarVM, not Parrot. nine (Stefan Seifert) then started Inline::Perl5 at YAPC::EU 2014. Within a couple days this new NativeCall based approach had already established itself as a great approach for delivering P5 interop, once P5 object destruction has been dealt with. It looks likely to me that this project will assimilate aspects of diakopter's unimplemented proposed P5 Interop design which in turn had assimilated blizkost.

Alternatively, once Perl 6 is sufficiently complete, it might be "relatively easy" and compelling to implement a Perl 5 compiler in Perl 6. So that'll be another plausible approach to using some CPAN modules.

[educated_foo]

When I last paid any attention, Perl 6 was intended to be able to run Perl 5 code unmodified, and allow new Perl 6 code to interact with old Perl 5 code. Of course, maybe the spec has changed since then.