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. (CGI.pm, 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
