The Perl Journal December 2002
Writing Perl modules is easy, as witnessed by the nearly 4000 modules available on CPAN (the Comprehensive Perl Archive Network). However, writing Perl apps that depend on multiple modules and that must be installed on multiple platforms is not so easy. Sure, Perl is a platform-neutral language (mostly). And sure, we have a great resource in CPAN and its CPAN module that, in theory at least, installs any module you need.
But theory and practice quickly diverge when you try to distribute a Perl app of any significant complexity to a varied group of users. Max Schubert, whose article "Making a Cross-platform Installer with Perl" appears on page 6, can attest to this. The complexities of third-party module dependencies, platform-specific Perl behavior, and even platform-specific module bugs all became significant hurdles for him on the way to delivering an app.
The reality for most complex Perl applications is that, unless the app is distributed in multiple OS-specific forms, users need some sort of Perl expertise to troubleshoot the installation. Perl's open, extensible, modular form gives you huge flexibility. I don't know about you, but I love knowing that I don't have to reinvent many wheels in my Perl code. But the price we pay for this flexibility is module-dependency complexity. This is why some people have argued that such complexity holds Perl back from true success in the enterprise.
Of course, there have been attempts to address this. James Tillman's PAIX project (http://www.sourceforge.net/projects/paix/), for instance, a is a cross-platform installer designed to cope with the installation hassles he encountered in his work on the Guido Tk app builder project (http://www.sourceforge.net/projects/guido/). PAIX is a fine start, but what we really need is a seamless installation facility built into Perl itself. There are some hints that Perl 6 may provide this. In a May 2002 posting on use Perl;, Larry Wall and Damian Conway were asked what modules were likely to be included in the base Perl 6 distribution. Their response was tantalizing:
It's impractical to ship Perl 6 with a thousand modules, so we're seriously considering shipping it with almost none, and instead making the process of downloading and installing appropriate SDKs highly safe and transparent.
Since then, there doesn't seem to have been a lot of discussion about the issue, perhaps because it has gotten lost in larger issues. There are, after all, other criticisms being laid on Perl's doorstep—it's not readable enough, it's too tightly coupled to UNIX, it's too hard to integrate C/C++ libraries. All of these problems limit Perl's ability to scale, and all could potentially derail Perl's adoption. Some people say these issues already have hurt Perl, and that it is losing out to languages like Python because of it. Whether this is true and whether the creators of Perl 6 find a wise and practical solution to the installation question, we know that they face a balancing act—making Perl scalable on one hand, while on the other keeping the flexibility of the "more than one way to do it" approach that has been such an integral part of Perl's success.
Kevin Carlson
Executive Editor
The Perl Journal