Perl6 is at least as good as Perl5 for everything Perl5 is good at.
No. It is not. Don't believe me? Here is a short list of classic selling points for Perl 5 that Perl 6 clearly loses on.
1. Performance. Back in the 1990s, Perl hit a sweet spot of being quick for development while still being fast enough for a wide variety of tasks. It still performs reasonably well versus other scripting language. Every time I looked at Perl 6 it failed to be fast enough for anything interesting to me.
2. Library support. Any argument for Perl quickly lists CPAN. It is a large part of why people adopted it in the first place. Perl 6 loses to every major language, including Perl 5, on this. If you need to do anything from connect to a database to sending email, Perl 6 loses.
3. Backwards compatibility. Perl has a history of being careful with backwards compatibility, starting with Perl 1's unit test suite back in the mid-80s. (It would be decades until other language communities caught up.) Most organizations currently using Perl 5 use it because they already have existing code in Perl 5. Their primary motivation for staying on Perl is that they don't want to rewrite their code. Perl 6 requires a rewrite of their code.
2. With Inline::Perl5[1] this should be a non-issue. The short code snippet in the README at the github repo referenced should give you the idea.
3. Having not been released yet, Perl 6 has zero history on backwards compatibility, so there's no way to assess whether it's relatively better or worse than Perl 5.
That said, I don't necessarily support the original statement that Perl 6 is a superset and at least as good as Perl 5 at everything. I just wanted to address your specific statement regarding library support.
We don't agree on #2. Inline::Perl5 is better than I would expect, but there is still an issue. For example, Perl 6 uses garbage collection instead of reference counting so modules like http://search.cpan.org/dist/ReleaseAction/lib/ReleaseAction.... no longer work like they did in Perl 5. (Yes, that module is used in production code. And I happen to know of several independent re-creations of the same functionality that are used in the same ways in other production code.) I am sure there are other examples.
Granted, this a module that depends on a quirk of Perl 5 behavior. But even if only 5% of CPAN modules hit such a nasty quirk, dependency chains are long enough that most non-trivial applications will have some dependency that breaks somewhere. If I have a library that uses DBIx::Class, Moose, and Catalyst with some interesting plugins, would you care to bet money that it will work with no issues under Inline::Perl5?
On #3, what backwards compatibility means is "compatible with what you already have". Perl 6 immediately loses on that to Perl 5 because nobody has Perl 6 legacy code bases. Ideally this wouldn't be an important fact. But it is an important use case. Many organizations today are only staying on Perl because they do not want to rewrite their code. If they hit the point where they would be willing to do a Perl 5 to Perl 6 migration, there is no reason why they wouldn't consider a Perl 5 to Python 3 migration instead.
While I grant you there are probably modules with problems, I will state for the record that I don't consider any module that relies on specific undefined behavior that could stop functioning as expected due to a regular Perl 5 point release to be the problem of Perl 6. If Perl 5 could break or change its functionality by changing exactly when they deal with reference counting and destroy objects, then it's a time bomb in production anyway.
That said, your complaint in #2 was about Perl 6 losing to every other language in library support, but I think we've established it's nowhere near as bad as that. It's not perfect, but it's definitely not barren. There's a few tens of thousands of modules Perl 6 can try to use, and there's a fairly good way of knowing if they will work or not, since most have good tests.
Your original complaint for #3 was also about companies needing to rewrite all their code. I think Inline::Perl5 goes a long way towards addressing that as well. It's not perfect, but when considering "Their primary motivation for staying on Perl is that they don't want to rewrite their code. Perl 6 requires a rewrite of their code." I think it affects that point of view.
I think you have somewhat valid points, I just don't think they are nearly as solid as initially presented.
...module that relies on specific undefined behavior...
You call Perl 5's use of reference counting "undefined behavior"?
It has been documented behavior for as long as Perl 5 has existed. The resulting destruction mechanics have been relied on by the core module http://perldoc.perl.org/SelectSaver.html for the same time. Furthermore any interesting XS program is likely to make use of the relevant macros SVREFCNT_int and SVREFCNT_dec.
Therefore this is NOT something that can be changed in a point release. It is a fundamental part of how Perl 5 works. And the fact that it is a fundamental incompatibility with Perl 6 plans is something that people have been aware of for a decade.
> You call Perl 5's use of reference counting "undefined behavior"?
No, I call counting on the fact that items with no references will be reclaimed (triggering DESTROY) immediately when they go out of scope undefined behavior. The fact that it happens very fast in most cases because it's reference counted and not garbage collected is not something that should be counted on. In fact, I'm pretty sure there are cases where in very tight loops, DESTROY isn't called immediately on scope end. I vaguely recall having to deal with that problem (but it could just as likely been a bug of mine that appeared to indicate that until I found it).
Followup, since it's too long since my reply to edit:
How are you assuming Inline::Perl5 works? Did you look into it and these are issues you found, or are these from how you assume it works?
Inline::Perl5 spins up an embedded perl5 interpreter (libperl I assume), and handles the data marshaling transparently. I assume (having not looked too closely at it's implementation), that it's sort of like a reverse XS. It looks into the perl5 guts, runs perl5 code, and exposes variables and functions to Perl 6. I see no reason to assume it wouldn't be using SVREFCNT_int and SVREFCNT_dec or equivalents as needed on scope changes to handle this.
In fact, looking at the Inline::perl5 repo now, it appears they are doing quite a bit with the refcnt functions[1].
> Having not been released yet, Perl 6 has zero history on backwards compatibility, so there's no way to assess whether it's relatively better or worse than Perl 5.
Well, uh, it's not backwards-compatible with Perl 5. Yes, yes, I know, "It's a different language." So why is it called "Perl 6?" The name is very much designed to tell us "this is the one after Perl 5." Insisting that everyone evaluate it as a greenfield language is an incredible insistence upon cognitive dissonance.
> is an incredible insistence upon cognitive dissonance.
It seems like one more (maybe even initially unintentional, I don't know) gag of many of them. Python was named after Monty Python, but Perl 6 lives a Monty Python life. Remember the "Parrot"? The support for it in Rakudo was suspended only some months ago:
"At 7:30 the room grew quiet, and the small throng of geeks migrated into the "Kanbar Forum" room." "There was already a browser on the screen that was displaying the Perl6 home page at Perl6.org, and two more tabs appeared to be IRC logs "for #p..." The quiet chatter turned to applause when Larry Wall finally walked out onto the stage. Then he made shadow puppets on the screen with his fingers — and left."
Once you accept the spirit, it's clear that nothing should remain "sacred." Not even the consistent naming of the language.
But with Inline::Perl5, it is, which I keep trying to point out. I think Inline::Perl5 may be a bad name for what is essentially "Interop with all your Perl 5 code and modules seamlessly in Perl 6, including XS".
But the other five aren't different languages, they're different versions of the same language. (And if it weren't for the Perl 6 debacle I think what we currently call Perl 5.22 would be something like Perl 6 or even Perl 8 or 9.)
> 1. Performance. Back in the 1990s, Perl hit a sweet spot
> of being quick for development while still being fast
> enough for a wide variety of tasks. It still performs
> reasonably well versus other scripting language. Every
> time I looked at Perl 6 it failed to be fast enough for
> anything interesting to me.
Yeah, performance sucks for Perl 6. Simple reason - first make it work, then make it fast. It's just been announced like yesterday that there's gonna be beta releases before the first stable release.
My money is performance will get better between now and Perl 6, v1.
No. It is not. Don't believe me? Here is a short list of classic selling points for Perl 5 that Perl 6 clearly loses on.
1. Performance. Back in the 1990s, Perl hit a sweet spot of being quick for development while still being fast enough for a wide variety of tasks. It still performs reasonably well versus other scripting language. Every time I looked at Perl 6 it failed to be fast enough for anything interesting to me.
2. Library support. Any argument for Perl quickly lists CPAN. It is a large part of why people adopted it in the first place. Perl 6 loses to every major language, including Perl 5, on this. If you need to do anything from connect to a database to sending email, Perl 6 loses.
3. Backwards compatibility. Perl has a history of being careful with backwards compatibility, starting with Perl 1's unit test suite back in the mid-80s. (It would be decades until other language communities caught up.) Most organizations currently using Perl 5 use it because they already have existing code in Perl 5. Their primary motivation for staying on Perl is that they don't want to rewrite their code. Perl 6 requires a rewrite of their code.