Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

schwern (1528)

schwern
  (email not shown publicly)
http://schwern.net/
AOL IM: MichaelSchwern (Add Buddy, Send Message)
Jabber: schwern@gmail.com

Schwern can destroy CPAN at his whim.

Journal of schwern (1528)

Sunday July 01, 2007
03:42 PM

Why no "useful" modules in the core?

[ #33652 ]

Everyone once in a while someone says: Hey, we should ship an XML parser with Perl! Or DBI. Or Template Toolkit. Or whatever. Usually because lots of people would find that useful. And they're right, lots of people would... and lots of people wouldn't.

There's lots of old modules in the core that at some point or another someone thought it was a great idea to ship them with perl. Text::Soundex, Class::Struct, SelectSaver, Dumpvalue, Selfloader, even CGI.pm. 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 consider putting XML modules into the core because people find them useful. 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 in the core 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 CGI.pm. Years ago CGI.pm was the best thing out there for CGI (and many thanks to Lincoln Stein for that) but now there's much better CGI solutions on CPAN. CGI.pm gets an artificial boost to its popularity due to the perception that it is the "official" CGI module and its elevated position of convenience because it comes installed with perl. All other CGI modules have to work twice as hard to be noticed because of this.

Some people 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! But what about QT? 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.

But a bad solution does not mean there's not a problem. It needs to be easier to get the necessary tools for your programming niche. PHP solves this problem by bundling everything into the core, and even though the solution is awful it is a solution and PHP is easier to use than Perl "out of the box".

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.

Seriously. Perl is Open Source. Grab the 5.8.8 source distribution, grab whatever CPAN modules you like. Put them into the ext/ source directory. Release. Talk to p5p and maybe you can get it "blessed".

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. Or an ISP. Or "best practices". Publish these lists and then distributors of Perl, like Redhat and Debian, can know what modules to package.

Lots of people complain about this problem, I must have heard it from a half-dozen people at YAPC. Now you know a solution. Implement it.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • This is similar to the SDK idea I posted [perl.org] some time ago. I still haven't had time to take that particular idea further, but creating an SDK to handle a known Database install, or Templating install or whatever, would seem a better idea than bundling them into a single core distribution.

    • This is the same SDK idea that has been knocking around since... well, certainly since I first went to a Perl conference in (I think) 2000 :-)
  • I don't like the idea either. Maybe a re-think of "core" should happen. I typically install Perl and then I have a list of standard modules that I use and they get installed via CPAN. Everyone and their mother is going to have a different list of what they consider useful. Keep the install as lean as possible. If I want something, I will get it.

  • I don't like the idea of alternative Perl cores. I'd prefer add-on packages, which would be like bundles, except they'd include everything and the kitchen sink, for specific distros. They'd include everything but the core perl distro.

    It would be a bit like PPM distributions for ActivePerl, or APTGET packages for some distros of Linux.

    The good thing is that there is no clash if you want the module bundles of two different "cores". You ought to be able to just install both, without installing Perl twice.

    There