Re^4: The current state of Perl6

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.

Comment on Re^4: The current state of Perl6 Select or Download Code

Replies are listed 'Best First'.
Re^5: The current state of Perl6 by Anonymous Monk on Apr 19, 2010 at 13:01 UTC
Well the point is that for any thing that could you could do with the Perl 5 standard library should either be available with Perl 6 language or the standard library. If some thing was there in Perl 5(Even as a module) and not in Perl 6 why should some one bother to shift to Perl 6?	[reply]
Re^6: The current state of Perl6 by moritz (Cardinal) on Apr 19, 2010 at 13:07 UTC
Because Perl 6 might be much better suited for actually solving your problems. Or maybe because you don't care about that "some thing" that can't be done in Perl 6, because you don't need it at all. I'm sure I won't stay with Perl 5 just because Lingua::Romana::Perligata exists as a module for Perl 5 but not for Perl 6.	[reply]
Re^7: The current state of Perl6 by Anonymous Monk on Apr 19, 2010 at 14:53 UTC
excuse me I believe that module should be in Acme:: namespace	[reply]
Re^8: The current state of Perl6 by moritz (Cardinal) on Apr 19, 2010 at 14:57 UTC


XP is just a number
	PerlMonks