At 10:56 AM +0300 5/30/06, Amir E. Aharoni wrote:
I wouldn't say that it's the minimum for the first production version,
but as my 2 cents, i'd like to point out that i was always pissed off
to read about fine modules in the Perl Cookbook and Damian's Best
Practices only to find out that i have to download them from CPAN. My
previous workplace was very anal about installing software from the
web - they hardly let me install ActivePerl - and i'm sure that it's
not the only one. I'm talking about modules such as Tie::IxHash or
Readonly. Rule of thumb: If a module is good enough to be recommended
by an important Perl book, then it should be considered for standard
distribution too.

I think that a clear distinction should be made between modules that are prerequisites for using Perl in production, discussing which is what this thread started out as, and modules that should be "in the standard distribution" aka bundled with Perl.

As I recall, it is Larry's wish that the standard distribution for Perl 6 be quite small, so that people are encouraged to use CPAN. And I agree.

Certainly, it should be a lot smaller than the module set with Perl 5.

Part of this is accomplished by rolling a lot of the functionality of those modules into Perl 6 itself, rather than being extensions. Eg, the functionality of modules like 'Readonly' would be built-in.

For most CPAN modules, it is actually best for them to remain as separate on CPAN, which assists in their being updated independently of the core and/or making it easier for developers to make more significant changes. And users can also feel more free to try alternative solutions than simply sticking with one because it is bundled. (, I'm looking at you.)

Particularly, anything complicated and/or in an open-ended domain should be separate on CPAN. Modules for talking to databases (DBI), web servers (CGI, LWP), processing complex things like dates and times (DateTime), and various other external things should remain separate.

-- Darren Duncan

Reply via email to