|There's more than one way to do things|
Perl with Everythingby tomazos (Deacon)
|on Feb 07, 2006 at 18:17 UTC||Need Help??|
One of the main problems I have found with Perl in a production environment is the installation of Perl modules.
If you give a Perl program to someone and they run it on a different machine, they need to download and install any Perl modules that your script depends on.
Contrast this with Java or .NET with a monolithic 100mb+ installer that installs all of the libraries (modules, shared code, etc) in one hit. There are many more Perl modules available (through CPAN/PPM) than Java or .NET libraries - but the standard set that you get when you install Perl is much smaller.
CPAN, PPM and PAR go a long way to addressing this problem much of the time, but it is still an extra step a Perl program user has to learn and take. Many times I have had to defend Perl over these extra steps.
Why can't we have a Perl distribution that includes a maximal amount of CPAN modules, rather than a minimal amount? These days, I would be fine with a 200MB Perl installer if I knew that I could write programs that relied on a much larger variery of modules than the standard set with no extra work from my users, and no PARing step for me.
I guess my question is why the standard set of Perl modules so small when the number of CPAN modules is so big? Was it a quality issue? Is there legal issues with bundling CPAN modules? Is there a technical reason why you can't bundle more CPAN modules in a standard Perl distribution?
Just some thoughts.