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.