An interview with Paul Barry.
WHY DID YOU WRITE YOUR BOOK?
I needed it for a final year software engineering module that I teach. Selfish, I know, but that's the real reason. I also firmly believe that every student of software engineering should have a passing knowledge of what's involved in programming the network, as the dominance of the Internet has moved the study of computer networking into the mainstream. An old marketing slogan at Sun Microsystems went something like "The network is the computer". A slogan it may have been, but it really has come to pass.
SO IT'S A BOOK FOR STUDENTS THEN?
No. Not entirely. Obviously that's the book's primary audience. However, I think there's plenty in the book for sys admins and network managers, too, especially Chapter 2 (on Ethernet analysis) and Chapter 5 (on network management with SNMP). Perl programmers looking for a thorough introduction to programming computer networks will also get a lot out of it.
WHY USE PERL TO PROGRAM THE NETWORK?
I teach a number of networking courses that have a high programming content, and I find my students respond well when Perl is used. This allows me to spend more time explaining the networking side of things, and less time explaining the ins-and-outs of the programming language. Perl has matured along with the Internet, and it has features that are of huge benefit when programming networks, including great in-built Sockets support and a large collection of networking add-on modules. It's also a fun language to program, which helps. So, I'd answer your question with another: why not use Perl to program the network?
HOW DOES YOUR BOOK DIFFER FROM LINCOLN STEIN'S "NETWORK PROGRAMMING WITH PERL"?
I get asked this a lot. Lincoln's book (which is great, by the way) is very much the Perl version of the network programming classic by W. Richard Stevens, called "UNIX Network Programming". In fact, Lincoln's table of contents and style somewhat mimic that of the Stevens' book. The Stevens' book targets C programmers, and is the definitive network programming reference for that language. Lincoln's book is the definitive network programming reference for Perl programmers. All the details are there, which helps explain why Lincoln's book has twice as many pages as mine. Lincoln's book assumes you are already a Perl programmer, mine does not, and this explains my inclusion of a 35 page Perl tutorial as my first chapter. I come at things from the perspective of the reader wishing to understand why and how the network is programmed the way it is, and I use Perl as a demonstration tool. Of course, there's a certain amount of unavoidable overlap with some of my content and some of Lincoln's, but we are coming at the material from different angles. There's also significant and very valuable material in both books that is unique to each. I guess Lincoln's book is to "Programming Perl" as my book is to "Learning Perl". Same general subject area, but very different approaches. Of course, both books are valid as they service different reader needs. My book is designed to be taught from, Lincoln's is designed to be referred to. The Perl community needs both types of books.
SO YOU THINK THERE'S ROOM FOR BOTH BOOKS?
Absolutely. I never intended mine to compete with Lincoln's, and I'd be worried and a little disappointed if people think it does. It's not an either-or decision. I've said this before and it is worth repeating: I saw no value in producing a "me-too" book. Such an effort would have provided little (if any) benefit to the Perl programming community.
ARE YOU WRITING ANOTHER BOOK, AND CAN YOU TELL US ANYTHING ABOUT IT?
Having just finished this one, I'm a little hesitant to start another so soon. Writing takes a lot of time, and it tends to be done mainly outside "office hours", so it's a big commitment. That said, I do have some ideas, and I can tell you that Perl figures in most of them.