Programming Perl, Third Edition
Authors: Larry Wall, Tom Christiansen & Jon Orwant
Publisher: O'Reilly & Associates, Inc.
Price: $49.95 US
Reviewer: Paul Barry
The Perl programming community had much to celebrate this year. Shortly after the millennium, along came the first major release of Perl since the middle of the last decade, when Perl 5 made its debut. Perl 5.6 was a long time cooking, but it is here now. And, of course, we can't have a new release of Perl without an update to “The Camel”, the Perl bible: Larry Wall's Programming Perl.
The third edition of Programming Perl starts being different from the second edition as early as the cover. It's right there, at the top, the Perl mantra: “There's More than One Way to Do It.” This phrase, more than anything else, sums up why Perl differs so dramatically from most other programming technologies. Perl isn't just a programming language, it's a culture, and this book—more than any other—is your guide, introduction and reference to the culture that is Perl.
It's not just the cover that's different. Practically all of the content in this edition has been rewritten, revised, reorganized and expanded upon. There's now well over 1,000 pages, up from the 600 or so pages in the previous edition. What used to take nine chapters, now takes five parts and a whopping 33 chapters! This reflects the extent of the rewrite that this third edition represents.
Part I, “Overview”, is a high-level introduction to the Perl language and its culture. The goal is to give the reader an idea of the flavor of Perl, and the authors succeed at doing just that. But, be warned, this is not a tutorial for those of you wishing to learn to program Perl. In fact, this is the wrong book if you are new to Perl. This book is a reference. I like to tell people that “The Camel” is the second Perl book they should buy.
Part II, “The Gory Details”, is just that—gory. In 13 chapters, the reader is bombarded with a very detailed description of Perl as a programming technology. This can be very heavy going if you read the book straight through (as I did for this review), but, when used as a “dip in and sample” reference text, the material is easier to digest. Again, this book isn't a tutorial—it is the definitive description of the language. There's an awful lot of good material here. I was pleased to see regular expressions (Perl's programming language within a programming language) get its own chapter, as well as a greatly expanded treatment. There's over 60 pages of patterns and regular expressions in Chapter 5, “Pattern Matching” and, although it's all great stuff, my head was spinning by the end of it!
Part III, “Perl as Technology”, has chapters covering Perl's support for Unicode, IPC, Threads and Compilation. When it comes to Unicode and Threads, Perl is playing catch-up with other programming technologies (most notably Java). But, hey, the thought of using Java fills most Perl-folk with dread, so having to wait for these features to appear in Perl has always been tolerable, even though their implementation may still be classed as “experimental” in Perl 5.6 (as is the case with Threads). Additional chapters cover using Perl from the commandline as well as using the debugger. An extra (and very welcome) chapter on extending Perl with, and embedding Perl in C, rounds off this part of the book.
Part IV, “Perl as Culture”, is all about community. The reader learns the importance of sharing their code with others (to help make the world a better place), as well as how to protect their code both from themselves and from an increasingly unfriendly Internet. The chapter “Common Practices” is full of useful advice both for the novice and the expert Perl programmer. Another welcome addition is a chapter on the issues surrounding code portability, and things to look out for when writing Perl code that will be deployed on disparate systems. A good programmer is a lazy programmer in the Perl world, and rather than have everyone ask you the same questions over and over again about your code, you produce documentation to go along with (and append to) any Perl modules you write. To this end, Perl provides POD (plain old documentation) and Chapter 26 tells you all you would ever want to know about this simple markup technology. The final chapter in Part IV is called “Perl Culture”. As everyone likes a good story, we are presented with a brief history of how Perl came to be. And what would a culture be without poetry? Also included are samples of the Perl poetry phenomenon. Competitions are held on a regular basis and poetry contributions are welcome.
Part V, “Reference Material”, provides details on Perl's built-in variables, functions, standard library and Perl's diagnostic messages. A nice touch in the “Functions” chapter is the use of descriptive icons to indicate the side-effects each of the built-in functions have on the Perl run-time environment. I was disappointed to see all of the standard modules listed but only a handful of them discussed in detail. The authors cite space constraints as the reason for this, but I will miss this material. Granted, all of the standard module documentation is available on-line (and it comes with the Perl distribution), but there is something to be said for having it in printed form. Perhaps the time has come for a separate volume on the Perl standard library?
To round things off, there's 29 pages of “Glossary”. You will not find a more entertaining glossary in any other computing text, anywhere. Imagine that, the word “entertaining” and the word “glossary” in the same sentence! Check out the entries for: algorithm, bucket, C, conditional, dweomer, eclectic, freely redistributable, funny character, hubris, impatience, invocation, laziness, Pern, portable, RTFM, script kiddie, shebang, string and (my personal favorite) UNIX.
My copy of Programming Perl, 3rd Edition was a very early printing and suffers a bit as a result. The authors fell over themselves trying to finish the book in time for the Summer 2000 Perl Conference, and a few things made it through the quality control checks that shouldn't have. For instance, in my copy, the black chapter tabs for Chapter 31 and 32 are reversed—what reads “Modules” should read “Pragmata” and vice versa. Another minor annoyance surfaced while I worked my way through Chapter 15 on Unicode. The author's discussed the utf8 pragma, so I looked up use utf8 in Chapter 31, “Pragmatic Modules”, in Part V, only to find that it wasn't there! The material's there, in Chapter 15, but it should also be in the Reference Part of the book. The index needs a little bit of tidying up, too. The on-line errata maintained at perl.oreilly.com indicates that the authors are aware of these problems and that some have already been fixed in more recent printings.
All in all, this is a great book, and the third Camel is the best Camel yet. It is written in a style and humor that is all its own (and which I suspect comes mostly from Larry Wall). The authors are all respected members of the Perl community—there's the Inventor (Wall), the Caretaker (Christiansen) and the Chronicler (Orwant). Between them, they know more about Perl than any mere mortal could possibly be expected to remember, which helps explain why this book is the essential Perl reference. You will not find a more authoritative treatment of the language in any other book. Just remember: when buying your copy, make sure it's the most recent printing.
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- Designing Electronics with Linux
- New Products
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Dynamic DNS—an Object Lesson in Problem Solving
- Using Salt Stack and Vagrant for Drupal Development
- Validate an E-Mail Address with PHP, the Right Way
- Tech Tip: Really Simple HTTP Server with Python
- Build a Skype Server for Your Home Phone System
- Why Python?
- Drupal Is a Framework: Why Everyone Needs to Understand This
- Reply to comment | Linux Journal
29 min 22 sec ago
- Reply to comment | Linux Journal
1 hour 19 min ago
- Not free anymore
5 hours 21 min ago
9 hours 8 min ago
- Reply to comment | Linux Journal
9 hours 16 min ago
- Understanding the Linux Kernel
11 hours 31 min ago
14 hours 1 min ago
- Kernel Problem
1 day 3 min ago
- BASH script to log IPs on public web server
1 day 4 hours ago
1 day 8 hours ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?