Interview with Simon Cozens
Simon Cozens has written several Perl modules, has written for Perl.com (which he used to edit), and writes a regular column for The Perl Journal. Simon's latest book, Advanced Perl Programming from O'Reilly Media, will be available sometime during the summer of 2005.
The Perl Review: You've updated Advanced Perl Programming by Sriram Srinivasan. How much is different in the new version?
Simon Cozens: It's very different; in fact it's fair to say that it's a different book with the same title. Sriram's book was excellent, but it was a product of its time. Nobody knew back then what we'd be doing with Perl eight years down the line.
I've tried to maintain the ethos of the original book: to teach the Perl programmer what they need to know to do their job more effectively. But what it means to be an advanced Perl programmer has changed. Eight years ago, an advanced Perl programmer was someone who knew who to write modules, or mess with the Perl internals; nowadays, an advanced Perl programmer is someone who knows their way around the CPAN, and that's what I've focused on in the book.
TPR: Who do you think should read this book?
Simon: The problem with a title like "Advanced Perl Programming" is that people who aren't advanced can feel they should leave it alone. No! "Advanced Perl Programming" is to help people become advanced! So anyone who wants to write better Perl programs should read this book.
In terms of formally learning Perl, or if you're teaching yourself and want a gentle introduction, I think it's a good follow-on to Randal Schwartz's Learning Perl Objects, References and Modules; equally, though, it follows on from where Programming Perl leaves off and tries to convert what you know about the language into real-life application.
TPR: Some of the things you didn't keep in the second edition include working with GUIs, networking, and embedding Perl. Have the importance of these topics changed?
Simon: I think so. Again, it's a reminder of what's happened in the past eight years. For instance, nobody suspected that the web would become the ultimate cross-platform GUI.
Networking has become more important, to the point where the book can assume some prior knowledge of how it works. But the way we do it has changed; it's less about building your own clients and servers to implement a protocol, and more about grabbing the appropriate protocol implementation from CPAN. There's also been the emergence of the POE event layer, which has given us the potential to do networking in new ways, so I've covered POE in the book rather than more fundamental things about networking.
Embedding turned out not to be a big deal; very few new projects are using Perl as an embedded language. I covered embedding in the book I wrote with Tim Jenness, Extending and Embedding Perl, so I can legitimately feel that this is not through lack of information about how to do it...
TPR: The new edition focuses on the Perl "rites of passage", or the stuff an intermediate programmer seems to always reinvents, such as a templating system. How important is that to mastering a language?
Simon: We go on about reinventing wheels, but reinventing wheels is not a bad thing. In a way you have to reinvent the wheels. That's how we get better wheels, or else this would be The sed Review.
And yes, reinventing the wheel is a good way to learn more about the language. But the aim of the book, and, I guess, the aim of Perl, is to be pragmatic, to help you get things done quickly and easily, and to give you the tools you need to do that.
People will still reinvent the wheel after reading the book---in fact, I hope they will. But the difference is that after reading the book, they'll know what is already available, why it doesn't fit what they want to do, and how they can create something which does. Then hopefully they'll go out and invent a wheel which does something new and different and innovative, and we call that progress.
TPR: What's in the future list of the Perl rites of passage?
Simon: Oh, plenty of things. Date/time handling and email handling have recently seen a swathe of reimplementations. Web application frameworks, without a doubt; particularly with all the buzz going on around Rails in the Ruby community. My own Maypole was one solution to this, and was swiftly followed by Catalyst, another framework; I'm sure there'll be many more besides.
TPR: You added a chapter on Unicode and I think it's the best part of your book. Should we teach it to people sooner?
Simon: Would they listen? Unicode has an image problem, people think it's overly complicated and many, particularly from predominantly English-speaking countries, still can't see why it's a good thing. With my Japanese connections---I studied Japanese at university, and am moving back to Japan next year---it became a big concern for me. But it's still a hard message to get across.
Again, though, the world is changing and this is getting more important and people are starting to ask questions about it. I hope that as time goes on we can teach it earlier and earlier.
TPR: You kept less about Perl internals in this edition. Do you think that topic is less important? Or is it pretty well covered elsewhere, such as Extending and Embedding Perl (which you co-authored for Manning)?
Simon: Both! I think those who really care about Perl internals can get Extending and Embedding Perl, but most people don't need to know about it.
Simon: To be honest, it hasn't sold well. But it was never intended to sell well (don't tell Manning)---the more important thing for me was to get a good explanation of that information out and available to people, so that people who did need to know about really advanced hacking with Perl can get hold of the book.
That is part of the reason I left so much of the internals stuff out---the information is already available in Extending and Embedding Perl. I wouldn't say that Extending and Embedding Perl is particularly more "advanced" than Advanced Perl Programming in terms of the difficulty of understanding the material---just that Extending and Embedding Perl is more specialized, whereas Advanced Perl Programming has something to say to all Perl programmers.
TPR: You devote a chapter to Inline modules, and the sections on Inline::C use Perl's C API. Do you think that's the path for future Perl C extensions?
Simon: I think it's part of the future. The current Inline system is good, but it's not perfect. chromatic is doing some interesting work with the "native call interface", using the operating system's own ways of loading dynamic libraries and calling foreign functions.
The beauty of this system is that you don't need a compiler in order to build extensions, which would really make the Windows people happy. For this to really work in a nice Perlish way, though, we would need to automatically pull in and examine the header files to understand the structures and calling conventions. This is the part that hasn't been done yet, but it's a part that Inline can really help with.
Of course, I'm supposed to say that the real path to the future is going to be Ponie and the NCI stuff that's happening on Parrot. But I still think that's very much a long-term future.
TPR: You include hard problems like parsing and natural language processing. Were there other such problems that you wanted to include?
Simon: Oh, I wanted to include everything I knew about Perl! I've mentioned email handling, and that's a particular interest of mine; I thought about putting something about that in the book. I wanted to put more web stuff in there, but there wasn't room. But mainly I think we covered most of what I felt should go in there.
TPR: Nat Torkington got you started on a new Advanced Perl Programming in 2002. How does the final version compare to what you thought you'd write?
Simon: It's pretty close: the Unicode, Inline, Parsing and other chapters made it all the way through. We planned to put in the chapters on GUIs and networking, but they never materialized. I wrote one on Perl 6, but Perl 6 moves so quickly that anything you write is out of date - especially with pugs, which again, nobody could have predicted.
The chapter on advanced Perl techniques, the first chapter, is actually new, but I'm very glad that's in there. It kind of lays a foundation for everything else that follows. The one about database abstraction was also a last-minute addition; I'd been umming and ahing about whether or not to do it, but eventually I just sat down and wrote it one day, and it's in the book!
TPR: You wrote most of this book in XML, and I know you use XML to create the slides for some of your talks. Which tools do you use? Have you developed most of your own tools to do this?
Simon: Well, as my friend Stephen Turnbull says, SGML (and to a lesser degree, XML) is just a conspiracy to get everyone using xemacs. The psgml-mode in emacs is spectacularly good. I've tried a bunch of more graphical applications but nothing has come close to it for ease of use. The book's written in DocBook XML; I processed my own drafts of the book using xsltproc and then either Sebastian Rahtz's xmltex or the Apache fop processor. The structure of the book, the skeletons for each chapter, were produced by a Perl script I wrote, which also created a Makefile used for the processing.
Simon: I think it was Douglas Adams that said the best time to write a book is in the warm glow after finishing the last one. I know what he means, but like him, I'm not going to do it. I thought about a Maypole book; maybe one day, but we need to see where Maypole goes.
But not now. At the moment I'm very busy with my studies, finishing off a theological course before going back to Japan next year. I'm still a little involved in the Perl world and the writing world---I'm currently providing a listening ear and occasional advice to new technical authors, helping them put together book proposals and shape the content of their books. This is something I've wanted to do for a while. I think if I can write a book, anyone can, and I want to help them say what they want to say and get read.
At the same time, I'm looking for a publisher for another book idea, a non-technical book I've been writing for a year or so now.
And of course, I keep hacking and doing fun things with Perl. I'm currently messing about with a very exciting project which could well change the way we do web hosting. I thought I could retire gracefully, but unfortunately it seems that I just can't stop myself.
A review of Advanced Perl Programming, 2nd Edition appears in the Summer 2005 issue of The Perl Review.