The Comprehensive Perl Archive Network is an extraordinary institution. I know of nothing else quite like it in any other programming language. Larry Wall, the creator of Perl claims that his language makes easy programming tasks simple and the difficult tasks possible. It is the availability of freely downloadable modules from CPAN that contributes the most to these objectives.
My understanding of a Perl module parallels that of a C library. Just like a library file, a Perl module is made up of shrink-wrapped code that I can call from my own project. Once I know how it works, I needn't concern myself with its internals. Just like a black box, I can pass it parameters and data for processing. I need have no fear of me corrupting its name space, nor it corrupting mine.
Perl programmers avoid re-inventing wheels by sharing their work. Their generosity has made available a whole plethora of high-quality (mostly), self-documenting code covering areas as diverse as emailing, database, parsing engines, date manipulation, networking, space exploration, etc. It is really is difficult to think of a programming problem which has not been addressed in some fashion. Time and time again on the comp.lang.perl.misc news forum I see the experts' response to a problem; 'go to CPAN and download module ...' (see
www.cpan.org).
I suspect that most Perl programmers have the ambition to become the contributor of a well-used module to CPAN. It is at these would-be contributors that Tregar has pitched his text. Down loading a CPAN module is almost trivial. Contributing a module is only a little more complex; one submits a request for comments on an idea, then a CPAN Author ID and once that's in place the code can be uploaded. Typical of Perl, the whole process keeps formality to a minimum.
So, it if is all so simple, why is there a need for this book?
Among other things it springs from a need for portability and standards in code, proper documentation and code maintenance. Tregar also goes to some length to point out that Perl modules need not be written in Perl! Indeed three whole chapters are devoted to writing modules in C (both Inline::C and XS)! He suggests that this is often necessary when interfaces are needed to important C libraries. He claims that many of the more popular CPAN modules are in fact written in C.
Is it worth buying? Yes, if you're interested in the C part. I know of no other documentation. However, if all you are interested in is writing conventional modules, then I suggest its usefulness is doubtful. Yes, if one is to write modules that are to go up on the public domain on CPAN then the code needs to be good, but writing good code should be your objective anyway and there are better sources out there to help with that (see
www.perl.com).
Note that nowhere in the text does the author suggest 'use strict;' or 'use warnings;'. The source code examples all have file extensions of 'txt'! This smacks of sloppiness, echoed by the book's impoverished page layout and design.
