develooper Front page | perl.perl5.porters | Postings from July 2007

Why no (XML|DBI|WWW|Template) modules in the core? (was Re: Beyond5.10)

Thread Previous | Thread Next
Michael G Schwern
July 1, 2007 12:42
Why no (XML|DBI|WWW|Template) modules in the core? (was Re: Beyond5.10)
Message ID:
Johan Vromans wrote:
>> There are a lot of Perl programmers (and companies, and
>> sub-communities) that would find XML in the core to be completely
>> superfluous and useless. It's just really not a great example upon
>> which to rest your arguments.
> Wow! There are many, many, MANY things in the Perl core that may be
> considered bloat, and they are stil being added on a regular basis. To
> name some, how often do you use Text::SoundEx? shmget?
> Pod::InputObjects? Env? CGI::Pretty? Tie::Hash::NamedCapture?
> Module::Loaded? Archive::Tar?
> All of these modules are useful for some people, and bloat for 98% of
> the Perl population. Don't mention backward compatibility -- several
> of these modules were added after 5.8.

I think you just countered your own argument.  And its a very old argument
that was settled a few years ago.

At some point or another someone thought it was a great idea to have these
modules in the core.  And now, due to backwards compatibility concerns, we're
stuck with them.  Since its less work to just continue shipping them then to
remove them, there they remain.

Now you want to put XML modules into the core because you find them useful
now.  But a lot of people don't.  And at some point in the future few people
will find them useful.  And then we'll be pointing at XML::Parser and saying
"god, look at this bloat!"

And then what happens when XML::Parser::Of::The::Week we include in the core
goes out of vogue and everyone is using XML::Fancy::Parser?  The prime example
of this is  We're stuck with the old parser in the core and it remains
on life support with an artificial boost to its popularity due to perception
as the "official" version.

You like XML.  Great.  I have little use for XML but I do a lot of work with
databases.  Should DBI go into the core?  What about DBD drivers?  Which one?
 DBD::mysql?  DBD::Pg?  DBD::SQLite?  And how about GUI programming?  We
should ship with WxPerl!  And for the web folks, WWW::Mechanize and Template
Toolkit.  Oh, but if we include TT we have to include Mason because we don't
want to bless "one true templating library"...

I trust you see the problem with putting "useful" modules into the core.
Everyone's idea of what is useful is different and over time what is useful
will change until all those useful modules are nothing but dead weight.

This is why there are three reasons to add a module into the core:
1) It helps build Perl itself.
2) It helps install more modules.
3) It's a dependency of 1 or 2.

ExtUtils::MakeMaker is an example of #1.  Archive::Tar and CPANPLUS are
examples of #2.  Module::CoreList is an example of #3.

> OTOH, what is the first thing people do after installing Perl? Install
> Bundle::CPAN. Install LWP. If there's a set of modules that really
> belongs to the box than it's Bundle::CPAN and LWP [Note: Bundle::CPAN
> is partly, but not completely, in 5.10].

I agree that this is a problem, but shoving more modules into the core is not
a solution.  It would be great if there was *another* source distribution of
Perl that had LWP in it.  Or Wx.  Or DBI and a pile of DBD modules.  Or XML stuff.

Go make one.

You don't even need to do that much.  Just make a list.  A list of what is
considered the best modules for an XML developer out there.  Or a database
developer.  Or a sysadmin.  Publish these lists and then distributors of Perl
can know what modules to package.

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About