An Interview with Randal Schwartz and Tom Phoenix: Authors of "Learning Perl, 3rd Edition"by Bruce Stewart
Learning Perl, or the llama book as it is affectionately known, is considered the quintessential tutorial for the Perl programming language. Randal Schwartz and Tom Phoenix have recently finished updating the third edition of the llama book--a revision that involved a complete rewrite and made the book current with Perl 5.6.
We got together with Randal and Tom recently and asked them about the new book, the state of Perl, and if their jokes have gotten any better.
Stewart: Learning Perl is considered a classic text in the Perl community, and it has been a bestseller ever since its first release in 1993. What's new in this latest edition of the llama book?
Schwartz: Quite a few things. The text is completely new, there were no cut and pastes from prior editions. Regular expressions now get three whole sections. The exercises are now both Unix and Windows compatible, and they are more "real world" and better paced. Some sections were rearranged to fit a more natural flow of learning.
We cover element syntax ($a) before aggregate syntax (@a), which appears to eliminate any desire to type @a by students in our training courses. We've introduced "use strict", modules, and references earlier than previous editions. The phrase "like C" has been nearly completely eliminated, as has "like the Unix XXX command".
Phoenix: We also have more (and, we hope, better) illustrations in this edition. Neither of us is a graphic artist, so Jessamyn Read from the O'Reilly staff put together some nice pictures to help illustrate some concepts.
Stewart: Does the book have more footnotes than in previous versions? Are the jokes better?
Schwartz: I'm not sure of the exact count, but I suspect we introduced about twice as many footnotes. We hope the jokes are better: at least there are more of them, so there are probably more, better jokes.
Stewart: You've spent a lot of time teaching Perl. How closely does the content in the third edition of Learning Perl relate to your Perl courses?
Schwartz: Very closely. We transcribed our current Stonehenge courseware to make this book, rather than edit a previous edition of the llama. And the courseware has gone though at least a dozen major revisions since having been written as a derivation of the first edition of Learning Perl. The hundreds of students we've had the privilege of teaching have given us the feedback needed to really optimize the course, and that's now reflected in this new llama edition.
Phoenix: To me, one of the largest benefits of teaching was seeing how the exercises worked for the students in class. Nearly every exercise gives the student the chance to learn something more by trying it, so we hope that folks who want to study from the book on their own will benefit by working through the exercises.
Stewart: What's your favorite non-Perl programming language?
Schwartz: Smalltalk. As the only easily accessible pure-object language, I find it an essential learning experience to understand objects in other hybrid languages, like Perl or Java or C++.
Phoenix: I've been using nothing but Perl for so long, it's hard to say that I have a favorite one besides Perl. But I use a little (inline) C from time to time. That is to say, I use the amazingly cool Inline module to put some snippet of C into my Perl program.
Stewart: Have you looked closely at Ruby or Python? What do you think of them?
Schwartz: Ruby is Smalltalk with algorithmic syntax. I think it's interesting, but since Smalltalk already has a much larger market share, I don't quite see the point.
Python is Perl with only one way to do things, and a severe lack of a CPAN-like archive. I guess Python's interesting if you're into control and like to invent things yourself, but Perl's versatility lets me optimize for different things at different times, and it lets me leverage off of a lot of other people's work.
If Perl weren't around, I'd probably be using Python. If Python weren't around, I'd probably be (back) using Smalltalk.
Phoenix: I often tell my students that Python and Perl are about equally capable, but philosophically incompatible: Perl is jam-packed with shortcuts, while Python has essentially none. That makes Python easier to learn, in general; Perl students have to learn many of its common defaults before they can follow along in someone else's program. But Perl is easier to use, even at the expense of being harder to learn. That's a good trade-off, since you learn it only once, then use it again and again.
Stewart: I'm curious about your opinion on Perl's future. Has the dot-com meltdown hurt or helped Perl? Can Perl survive without intense Web development?
Schwartz: I think it's both hurt and helped. Fewer people are having to do more with fewer resources, and Perl's great for leverage to get a lot done with a little. However, fewer people are doing it, so there are fewer opportunities to siphon off some of that energy for public contribution to the core or take the fallout of cool projects to shove them into the CPAN.
Phoenix: I just got back from the 2001 O'Reilly Open Source Convention in San Diego. Nobody was talking about CGI programming there, but everybody was talking about Perl. Really, the Web is merely the most noticeable, not the most important, facet of Perl. One person at the conference pointed out to me that while waiting for the economy to reboot, many people are keeping busy by getting training in Perl. So, even though things aren't good right now economically, Perl's still chugging along.
O'Reilly Perl editor Linda Mui reports that Perl is remaking itself for this millennium in her Perl Conference 5 Dispatch.
To see a list of all of O'Reilly's Perl books, visit perl.oreilly.com.
Stewart: Have you noticed any economic ill-effects in your Perl consulting business?
Schwartz: The rising tide lifts all boats. I presume the receding tide does the opposite. But it's really whatever you make of it. I'm busier today than I've ever been, partly because I can now leave the country.
Stewart: Are there new areas in which you see Perl being used?
Schwartz: I don't see so many new areas as much as I see it just becoming much more essential. With all the Web stuff needed to glue this Web device to that database, and spit it into some WAP card to view on my Web-enabled phone, Perl is the perfect solution at nearly every step of the way. And the CPAN grows by five to fifteen modules a day, so there are a lot of people out there doing interesting, and essential, stuff with Perl.
Stewart: What is your take on Perl's role in the emerging Web services space?
Schwartz: Again, glue. Glue, glue, glue. We need to hook legacy applications to Web tools, and Perl is great for reformatting and screen scraping as well as for being socket-savvy and standards-supporting. Good implementations of XML-RPC and SOAP permit pure Perl applications to achieve reasonable performance and ease of deployment.
Phoenix: I also see Perl being used more because of its built-in security features. Security is a bigger issue every month, it seems. But Perl's near total immunity to buffer-overrun attacks, and its dataflow security analysis ("taint checking"), to name just two features, can make a Perl program much more secure than the corresponding program in many other languages.
Stewart: You have been teaching Perl for a number of years now. How has the profile of your students changed over the years?
Schwartz: They've gotten shorter, I think. But seriously, over the decade I've been teaching, I've seen a strong move away from "the Unix system administrator" as our core student, to simply "general tool user", where the tool might be for Web, system administration, data wrangling, or even end-user application deployment. In fact, it's hard to find domain-specific exercises and material, given how broad Perl has become in the industry.
We've also seen a slow but steady uptick in the number of people coming to Perl as their first (and sometimes only) programming language. While the llama still deliberately does not address that market, we are looking at ways of including these newcomers-to-computing in future Stonehenge offerings.
Stewart: One of the amazing things about Perl has been the strength of the community that has grown up around the language. What do you think it is about Perl that engenders such passionate fervor from its advocates?
Schwartz: Simply put, it works. I can't recall the last time I read about a Perl bug in a production release of Perl. And that CPAN! Whoo! There's nothing like it in any other community I've seen, either closed or open source. Many of the solutions I offer on the newsgroups, mailing lists, or at communities like Perlmonks.org are merely a few lines long because I can push the rest of the work into the appropriate CPAN module call.
And that's a self-feeding fire. More active developers mean a stronger Perl implementation, and fatter CPAN, which in turn attracts more developers.
Phoenix: Perl is quirky, fun, and creative. It attracts people who are also quirky, fun, and creative. In addition to all of the useful and wonderful things people have made with Perl, there are also any number of nominally useless projects, including Perl poetry, obfuscated Perl, and modules to let you, say, write Perl in Latin. Now, we call these things "useless", but the Mona Lisa or the Eiffel Tower are equally useless. The fact is, once you have made Perl powerful enough to enable all of these kinds of play, even work gets to be more fun.
Stewart: What do you think of Perl 6? I gather the process has been a bit slower than expected. Have you been keeping up to date on the progress, and how involved are you in the development efforts?
Schwartz: I'm keeping my ear to the ground and making an occasional comment. I think there's been more than enough input for Larry to digest. If anything, we now have Larry with his mouth full of "P6 pie", and he's having a hard time swallowing it all, but people are already offering him seconds. I say, let him chew and swallow a bit, and see what results get produced. Ewww. Don't carry that analogy any further, please. Sorry, Larry.
Stewart: Is a rewrite from the ground up worth the effort?
Schwartz: The jury's still out. I think the act of reexamining the legacy Perl design decisions was very appropriate, not for today's problems, but for tomorrow's problems. I'm happy they didn't choose Java or C++ as the implementation language (yet). But the result better be revolutionary to justify the effort, not just evolutionary. And it had better run a lot of existing code (somehow, maybe with "use Damian" at the front), or it'll cause a pretty severe fork in the community, and perhaps there's no point to that.
For the latest information on Perl 6, read Simon Cozen's wrap-up of Larry Wall's annual speech, The State of the Onion, from the O'Reilly Open Source Convention.
Stewart: Currently the perl5-porters are wondering whether to include XML-RPC support in the standard Perl distribution. What do you think of this proposal, and how do you feel about putting more modules into the standard Perl distribution in general.
Schwartz: Maybe I'm spoiled, but making CPAN.pm a little more robust might be a better choice. The CPAN is a wonderful distribution mechanism, and I can't imagine that anyone using XML-RPC is not Net-connected. So, having said that, I'd keep it out of the core.
Phoenix: I tend to agree with Randal here. I'd like to keep the core small, but make it even easier for people to add on to Perl. In fact, the default installation should probably include a step of installing modules from CPAN, to encourage administrators to install most modules from the start.
Stewart: What, in your opinion, is the one thing that Perl really needs right now?
Schwartz: Three more cooperating copies of Larry, to get Perl 6 designed sooner, before the implementers wander away in boredom, and the market gets jaded by futureware announcements.
Phoenix: Perl has some of the best documentation available of any comparable piece of software. But no matter how hard people work on documentation, it's never quite as clear and complete as it needs to be. I don't know what the plans are for Perl 6 and documentation, but it would be nice if the docs were rewritten from scratch, with a master plan that would include a tutorial, an index, and an in-depth reference. Of course, that's a project that would take a team of skilled documentation writers many a day. We've got plenty of talented people, including writers, working on Perl, but writing documentation for no pay doesn't attract enough people for enough time to make my dream documentation system come true.
Stewart: Randal, most people in the Perl community know that you've been involved in a long-running legal dispute with Intel over some things you did while acting as a consultant for them. Would you like to give us an update on the situation?
Schwartz: Yes, I'm waiting for the Oregon State Supreme Court to issue an appeal ruling in my favor. For details, send email to email@example.com, or visit www.lightlink.com/fors/. Be sure to join my Yahoo group for timely announcements or discussions.
Randal L. Schwartz is a two-decade veteran of the software industry. He is skilled in software design, system administration, security, technical writing, and training. Randal has coauthored the "must-have" standards: Programming Perl, Learning Perl, Learning Perl for Win32 Systems, and Effective Perl Programming, and is a regular columnist for WebTechniques, PerformanceComputing, SysAdmin, and Linux magazines. He is also a frequent contributor to the Perl newsgroups, and he has moderated comp.lang.perl.announce since its inception. His offbeat humor and technical mastery have reached legendary proportions worldwide (but he probably started some of those legends himself). Randal's desire to give back to the Perl community inspired him to help create and provide initial funding for The Perl Institute. He is also a founding board member of the Perl Mongers (perl.org), the worldwide Perl grassroots advocacy organization. Since 1985, Randal has owned and operated Stonehenge Consulting Services, Inc. Randal can be reached for comment at firstname.lastname@example.org or (503) 777-0095, and he welcomes questions on Perl and other related topics.
Tom Phoenix has worked in the field of education since 1982. After more than 13 years of dissections, explosions, interesting animals, and high-voltage sparks during his work at a science museum, he started teaching Perl classes for Stonehenge Consulting Services, where he's worked since 1996. He travels to any number of interesting locations, so you might see him soon at a Perl Mongers' meeting. When he has time, he answers questions on Usenet's comp.lang.perl.misc and comp.lang.perl.moderated newsgroups, and he contributes to the development and usefulness of Perl. When not working with Perl, Perl hackers, and related topics, he spends his time on amateur cryptography and speaking Esperanto. His home is in Portland, Oregon.
O'Reilly & Associates recently released (July 2001) Learning Perl, 3rd Edition.
Sample Chapter 4, Subroutines, is available free online.
For more information, or to order the book, click here.