CPAN (was Re: [Israel.pm] The future of Perl)

[Jason Elbaum]

Offer Kaye wrote:

 > Here's a nice article regarding the future of Perl. What I found 
refreshing
 > is that it wasn't the old "Perl 6 and Ponie" show ;-), the article 
actually
 > manages to talk about Perl 5 and make some very strong points for its
 > future, separately of the success (or failure) of Perl 6. So read and 
enjoy
 > :-)
 > http://www.perl.com/pub/a/2004/01/09/survey.html


Thanks for this link. I was particularly interested in the discussion of 
CPAN. Some excerpts:

<quote>

One way to get a glimpse how Perl is used in the wild is to look at 
CPAN. I recently took a look at the modules list 
(www.cpan.org/modules/01modules.index.html) and counted module 
distributions by the year of their most recent release. These statistics 
are not perfect, but they do give a reasonable first approximation of 
the age of CPAN distributions currently available.

         1995:   30 ( 0.51%)
         1996:   35 ( 0.59%)
         1997:   68 ( 1.16%)
         1998:  189 ( 3.21%)
         1999:  287 ( 4.88%)
         2000:  387 ( 6.58%)
         2001:  708 (12.03%)
         2002: 1268 (21.55%)
         2003: 2907 (49.40%)
         cpan: 5885 (100.00%)

Interestingly, about half of the distributions on CPAN were created or 
updated in 2003. A little further analysis shows that nearly 85% of 
these distributions were created or updated since the Perl 6 
announcement in July 2000. Clearly, interest in developing in Perl is 
not on the wane. If anything, Perl development, as measured by CPAN 
activity, is quite healthy.

....

How much of this code is production-quality? It's quite difficult to 
say, actually. These modules cover a stunningly diverse range of problem 
domains, including, but not limited to:

     * Application servers
     * Artificial intelligence algorithms
     * Astronomy
     * Audio
     * Bioinformatics
     * Compression and encryption
     * Content management systems (for both small and large scale web sites)
     * Database interfaces
     * Date/Time Processing
     * eCommerce
     * Email processing
     * GUI development
     * Generic algorithms from computer science
     * Graphing and charting
     * Image processing
     * Mathematical and statistical programming
     * Natural language processing (in English, Chinese, Japanese, and 
Finnish, among others)
     * Network programming
     * Operating-system integration with Windows, Solaris, Linux, Mac 
OS, etc.
     * Perl development support
     * Perl/Apache integration
     * Spam identification
     * Software testing
     * Templating systems
     * Text processing
     * Web services, web clients, and web servers
     * XML/HTML processing

...and that's a very incomplete sample of the kinds of distributions 
available on CPAN today. Suffice it to say that hundreds, if not 
thousands, of CPAN modules are actively used on a daily basis to solve 
the kinds problems that we regularly face.

</quote>


Here's my problem: How can I possibly make effective use of a library of 
nearly 6000 Perl modules? Especially as I have no way of evaluating the 
quality of a CPANmodule without downloading, installing and testing it? 
Most of the subject categories above overlap, and modules aren't always 
catalogued where I might expect to find them. By the time I figure out 
whether the functionality I need exists in CPAN, and where it is, and 
which version of which module to try, and whether in fact it actually 
does what I need - often I might as well write it myself!

Add to that a further problem: I sometimes write Perl code to be 
exported to remote installation sites. I can't necessarily rely on which 
subversion of Perl is available there, let alone expect them to install 
CPAN modules just to run my code. They're users, not sysadmins. Result: 
I rarely use CPAN in my release code.

Surely I can't be the only one with these problems! Suggestions are 
welcome...


Regards,

Jason Elbaum