in reply to The current state of Perl6
There is an interesting parallel with Python 3, which was released around Christmas 2008. Python 3 code is not backward compatible to Python 2, but there are much fewer differences between Python 2 and 3 as there are between Perl 5 and 6. Mostly the code got tided-up and deprecated features removed.
So, is everyone using Python 3 now? No. The reason, according to the Python people I have spoken to, is the lack of third party modules. They like Python 3, but just can't use it. Let's hope that 'we' learn from that mistake before repeating it.
Re^2: The current state of Perl 6
by moritz (Cardinal) on Apr 19, 2010 at 12:03 UTC
|
I hope that Perl 6 doesn't fall into that trap. And I'm confident that it's not going to, because the differences between Perl 5 and Perl 6 are much larger than those of python{2,3}, thus offereing a larger incentive to migrate stuff.
Perl 6 - links to (nearly) everything that is Perl 6.
| [reply] |
Re^2: The current state of Perl6
by Anonymous Monk on Apr 19, 2010 at 11:51 UTC
|
I think that won't be the case with Perl 6 as they have found a way integrating existing CPAN modules with Perl 6 code. You are actually very right in pointing out this fact, Its not just a bare interpreter. The word production ready actually has a lot of meanings like availability of sufficient documentation, standard libraries, spec completion, stability etc. But you have to start some where like Python 3 did, there idea is to really backport the Python 3 stuff into 2.x. In their case they have something to migrate to, in our case our migration target isn't yet ready. So the focus should be first on spec completion first not migration. | [reply] |
|
they have found a way integrating existing CPAN modules with Perl 6 code
Wow! Really? Does anyone have a link to that?
| [reply] |
|
I think that's a bold exaggeration.
There's blizkost, which integrates parrot with perl5 (by loading the dynamic perl5 libraries). Currently that works to the point where callbacks in both directions work, simple method calls, numbers and strings.
Due to a bug in parrot that integration currently can't be used in Rakudo (or in other high-level langugages) for that matter.
Perl 6 - links to (nearly) everything that is Perl 6.
| [reply] |
A reply falls below the community's threshold of quality. You may see it by logging in.
|
Re^2: The current state of Perl6
by Anonymous Monk on Apr 19, 2010 at 12:06 UTC
|
the only thing you can learn from that is that you have to port all the(important) Perl5 modules --> Perl6 early so when it's out people won't be able to complain about this.
but since Perl6 is still in development devs will face serious bugs that they won't really be able to fix themselves because they don't know the internals of the compiler in order to fix those bugs. | [reply] |
|
It will be very disappointing if Perl 6 releases without a standard library. At the least all the standard modules with Perl 5 have to be available with Perl 6.
| [reply] |
|
That's a very odd view.
Why do think Perl 6 should ship with a vars module? Or with Encode, when buffers have .decode and strings .encode methods?
IMHO there are also a whole lot of modules in the Perl 5 core that have no good reason for being there (like Text::Soundex)
I also suspect that there will be quite a difference between "core" Perl 6 and Perl 6 distributions. I see no reason why "core" should contain something like CGI, but most distributions will probably ship something like that anyway.
| [reply] [d/l] [select] |
|
|
|