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.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SuperTuxKart 0.9.2 Released
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- SourceClear Open
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide