Writing Perl Modules for CPAN

Writing Perl Modules for CPAN teaches the reader the basics of creating Perl modules, all in a fashion that makes it right for CPAN. Touching all the necessary bases, Tregar walks the reader through the use of CVS and the process of using the upload screens on the CPAN web site to install code. The tour is well paced and thorough, though hardly exhaustive; after all, as Tregar points out, the Perl motto is "There's More Than One Way To Do It." What's certain is that by the time you finish this book, you will have learned one way to do it—the CPAN way.

The editing and production values are excellent in this attractive book. The table of contents can be viewed at http://apress .com/book/supplementDownload.html?bID=14&sID=616. The download site for source code accompanying the book is vaguely referenced in the book itself on the copyright page. Sam Tregar's web site is http://sam.tregar.com/, and on that site is a link to the Apress site. Sure enough, everything that should be there is there on an elegantly styled page at http://apress.com/book/ bookDisplay.html?bID=14.

I spoke with Sam Tregar in Westchester, New York, and discussed his career in Perl and the tidiness of his tightly focused book.

Sam Tregar: I started out my open-source career as a Tcl/Tk programmer at New York University. I went out into the job market as a Tcl/Tk programmer and found nothing, so I put Perl on my résumé thinking, "Well, I read Programming Perl..."

TPJ: Bingo.

ST: And, "Here's 10 sites to maintain, you start today." I sank for a year before learning to swim.

TPJ: So Perl has been very good to you?

ST: I'm having a lot of fun. Perl is expressive in ways that most languages aren't and gives me a sense of freedom when I'm coding that I rarely get with more bondage-and-discipline-oriented languages. But the real power of Perl is the Perl community, which is a fantastic resource.

TPJ: Back in the '70s and '80s, the Forth community was trying to create something like this but our numbers were in the hundreds, so we never achieved what can be achieved today when thousands of people are willing to give their time to a business model that was legitimized by the efforts of people like Richard M. Stallman.

ST: Larry Wall brings something new to the model—a sense of fun. He manages to guide the community in a way that discourages us from viewing [open source] as a fight to maintain control of something, which may be why so many fun and energetic people end up in Perl.

TPJ: What are you working on now?

ST: I'm a Perl programmer at About.com working for Primedia. I work on the Bricolage open-source content management system originally developed for Salon.com. It's a flexible HTML::Mason system with a data-definition language built into it. You define story types and assign code to them to format them for output and assign properties that decide how they handle user input. It's 100,000 lines of Perl—the largest system I've ever worked on. I've often wondered if it's the largest Perl program in existence!

TPJ: Did you read Extending and Embedding Perl (Tim Jenness and Simon Cozens, Manning 2002, reviewed in the November 2002 TPJ)?

ST: I loved it! The chapters that I wrote on XS could serve as an introduction to their book. You can do a lot with what I give people; maybe 50 percent of the modules on CPAN could be written just with what I provide. Their book obviously goes into far more depth on the subject of XS, in fact, and has stuff in it you can't get anywhere else. They've documented some really dark corners of the XS universe.

TPJ: Your book is focused on how to write a module, and specifically the CPAN way.

ST: I think I managed to codify a lot of the accepted best practices of the Perl community—the stuff that goes into all the best CPAN modules but wasn't already written down in one place. Extending and Embedding Perl more or less assumes you know how to create a Perl module. So I think the books are complementary.

TPJ: The open-source community may be the biggest, if not necessarily the most important, intellectual collaboration in the history of mankind.

ST: The interesting thing about CPAN is that it's a loose collaboration, despite the size it has reached. The central authority is hands-off. It's a vaguely controlled anarchy that manages to maintain itself. If you look at Apache, which is another very large collaboration, they actually vote on their mailing lists. Lately I've been doing a lot of work with DBI, which is sort of where the Perl community meets other communities like the Postgres community. The CPAN philosophy is "one person controls a module." The Postgres community wanted to share control of the Postgres database driver with all the Postgres developers and involve it in their voting system and arbitration.

TPJ: To some extent, your book herds the reader in a certain direction.

ST: There were many topics I considered exploring that I decided not to mention. I consciously decided not to leave too many loose ends. Some authors are in the habit of ending each section with, "If you want to know more about this, go off on this exit." I resist doing that. It's distracting. The reader wonders, "What am I going to learn if I do that? Let me put the book down and hit the Web." They end up going down some other corridor. On the other hand, when I do get in over my head, like in the CVS section, I do give pointers to other resources. I consider CVS a crucial tool and wanted to have that in the book, but I didn't want to write a book on CVS: There's already a great one. The great thing about working on Writing Perl Modules for CPAN was the sense that I was mostly providing things you couldn't get elsewhere. There's a lot of repetition in the technical publishing industry.

TPJ: There are also a lot of books that are too long.

ST: I'm a very slow reader, so I couldn't write a very long book. Programming Perl was a hard read for me, 800 pages.

TPJ: You must have the blue one...I learned from the pink one! Much shorter. No objects!

ST: CPAN would have been impossible without Perl 5. I'm looking forward to Perl 6; they're planning some useful features that will be useful to CPAN, such as allowing multiple versions of a module to be installed and used separately, and the ability to have multiple modules with the same name from different authors. The first of those features, allowing multiple versions, interests me the most. Probably the biggest single problem with CPAN now is that as its use proliferates in large applications, it turns into a sort of "DLL hell" situation where module X requires module Y version 1 and module Z requires module Y Version 2.

TPJ: It's already maddening keeping track of all this stuff. You're going to need a full-time module administrator to have a Perl programming team. But all software turns into that eventually, I guess.

ST: It's the cost of modularity: Suddenly you need a librarian.

TPJ