Slashdot Mirror
Programming Perl, 3rd Edition
The Scoop Longtime Perl fans know Programming Perl as the Camel, because of the cover animal. With the first edition in 1991, Perl programmers gained not only a charmingly appropriate mascot, but the ultimate language reference. True to form, this Camel's grown with the language. In the four years since the last release, it's increased in size by 67%.
Everything you liked about previous editions has returned, in one form or another. Additionally, this third edition covers the largest changes made for Perl 5.6 (actually 5.6.1, as the book's ahead of the current stable release by a bit) -- Unicode, threading, and more Perl guts.
While the previous editions were exceptionally well-written references, they were also aimed squarely at experienced programmers. This edition pushes back the starting blocks somewhat, providing a gentler introduction to the world of Perl. The wealth of new information is staggering, but as you'd expect from the luminous authors, even the core language reference is highly readable and entertaining.
What's to Like? Logically, the book is divided into five main sections. (Gone are the massive 80-page chapters of the second edition). The first section, one chapter, gives a good overview of Perl, as a language and a philosophy. It includes a quick introduction. The second section gives the language's gory details, covering just about everything you would need to know. It's arranged in terms of ascending complexity. The enhanced, extended, and improved regular expression chapter stands out as the best member of this group.The third section discusses Perl as technology. Here's where Unicode comes in, as well as the internals of Perl (through the internal compilation process, using the debugger, or using XS to extend Perl with C code). Everything here is quite good. Expectably dry subjects like Unicode or threading are readable and even a little entertaining. If you're not convinced, you can skip around and still learn quite a bit.
The fourth section is devoted to Perl as culture, with discussions about portability, security, good practices, documentation, CPAN, and a bit of poetry. The security chapter is quite good, but left me wanting more information. Any chapter here is accessible if you've made it through the second section, so feel free to pick and choose what you need to know.
Rounding up the spare bits is the reference section. Not only will you find descriptions of the special variables, built-in functions, and standard library, but the organization and presentation of these descriptions has improved. Functions have little annotations listing which magic variables they set, possible exceptions they raise, and the like. That accounts for 150 pages of the overall goodness. Don't skip the glossary at the end, if you're confused or looking for amusement.
What's to Consider? While it's a temporary conundrum, it's a little odd to read about features that aren't quite implemented yet. This is most noticeable in the Unicode discussions and the chapter on threading. Occasionally, the authors will describe a feature and then admit that the specifics will likely change. (Have a look at the documentation.) Granted, the bulk of the language is mature and stable, and the definitive guide can't very well get by with ignoring major features, but it reads a little oddly.The intended audience is still the serious Perl programmer. Dabblers and casual learners will find enlightenment and instruction. Realize, though, that while it's easier to start your journey here, absolute beginners would do well to explore a Learning Perl or Elements of Programming with Perl first. People who've programmed before (beyond dabbling with VB, or doing mouseovers in Web pages) should have little difficulty picking up the Perl language and mindset.
The only other possible improvement that comes to mind is expanding certain chapters. As noted before, there's more to say about security and efficiency. It would also be nice to have a chapter on common Perl idioms one might find in EFNet #Perl or at Perl Monks, or the latest Perl Mongers meeting. (Half of the fun is discovering and sharing new tricks and shortcuts.)
The Summary Part of being a good programmer is knowing where to turn for accurate and useful information. This is the place for all things Perl. If you use Perl regularly, put the new Camel on your shelf. Table of Contents- Overview
- An Overview of Perl
- The Gory Details
- Bits and Pieces
- Unary and Binary Operators
- Statements and Declarations
- Pattern Matching
- Subroutines
- Formats
- References
- Data Structures
- Packages
- Modules
- Objects
- Overloading
- Tied Variables
- Perl as Technology
- Unicode
- Interprocess Communication
- Threads
- Compiling
- The Command-Line Interface
- The Perl Debugger
- Internals and Externals
- Perl as Culture
- CPAN
- Security
- Common Practices
- Portable Perl
- Plain Old Documentation
- Perl Culture
- Reference Material
- Special Names
- Functions
- The Standard Perl Library
- Pragmatic Modules
- Standard Modules
- Diagnostic Messages
Glossary
Index
You can purchase this book at ThinkGeek.
Next
(Those books don't last like the old ones used to)
I wouldn't have expected a third edition of the camel just now. Isn't Perl6 coming out Real Soon Now? I understand it will introduce some significant new capabilities. Given that, I'd have waited.
--
Some keywords for the NSA in the Lord of the Rings universe: One Ring bind find Sauron quest Nazgul freedom
Seriously, I don't see much use for perl other than for programming server-side applications (i.e., the Slashcode which powers Slashdot's forum system, etc.). Until I do get into the server world, I won't need it.
"Ancillary does not mean you get to rule the world." --U.S. Circuit Judge Harry Edwards, speaking to the FCC's lawyer
Not surprising, since Perl is going the way of VB and becoming a bloated, hard-to-read language best suited for writing completely unmaintainable, uncomprehensible code.
Most people are moving to Python or Ruby, which are proving to be far more readable, extensible, and flexible languages than Perl.
Don't get me wrong--I used to be a Perl zealot, until the amount of crap that Perl adopted just sickened me to the point where I had to leave my first love and find something else that would be much more suitable to what Perl used to be perfect for... *sigh*
--
A feeling of having made the same mistake before: Deja Foobar
While electronic books can easily fix this problem, that's not the solution when you need to look at paper copies, whether at the terminal or on the toilet. Maybe there should be some way to 'register' the books, such that when the n+1(th) edition comes out, you can get it for a substanially less cost, because your initial purchase of the nth edition helped to make the n+1(th) edition possible. Or one could send in the cover of the nth edition and a S&H charge to get a copy of the new book. Or something along these lines.
If any computer book publishing company could do this, I would expect ORA to be the first to try such, given their helpfulness in the past and present. But with many standard 'things' moving so fast (XML, HTML, Perl, Python, etc), we need a some book upgrade mechanism in place ASAP.
"Pinky, you've left the lens cap of your mind on again." - P&TB
"I can see my house from here!" - ST:
For those who wish to be a little too hard core. The 1st edition which only covers version 4 is perfect intro to perl. After that, work your way through the man pages (in HTML). You'll notice many of the perl books are rehashes of the man pages. (I use man pages loosely, since all the perl docs can be seen in HTML and mush easier to read and navigate).
You didn't really just recommend ASP on Slashdot, did you?
--Just another Pimp A$$ Perl Hacker
El riesgo vive siempre!
I went from 0-60 lines of Perl in no time with this book. I never have time to read it anymore because everyone at work keeps stealing it!
There is no longer anything that can be done with computers that is nontrivial and clearly legal. -- Paul Phillips
Its the latest of reference tomes for perl. Like any other longstanding tool(language *and* documentation), it has evolved. The language itself is terse and therefore some feel that it reqires significant documentation to cover. I'm still kind of sad the book is so long now(It easy to write volumes, difficult to be informative and brief(but worth it)). Perhaps it was an exercise in deep analysis for the authors since a total rewrite of the language is in the works.
That's not to say it still isn't a useful language. But pretty it ain't. It's like a programmer's desk. The ugliest ones are the where the most useful code comes from because he's not wasting time watering plants and wiping fingerprints off the screen and chastising anyone messing up his cubicle.
My copy of second edition is over 4 years old (September 1996 from the printing history) does this really count as recent?
--
01 13 19
TVDJC TDSLR AZNGT NWQSH KPN
I vaguely suspect this entire post is not "insightful" but rather "flamebait", and in fact, may be indicative of an individual who has a highly organized set of troll and dummy accounts with which to moderate inane posts into a position where they will be perceived by others in such a way as to engender pointless debates.
If that is not the case, I would like evidence that any serious comparison of the 2nd and 3rd editions went into recommending buying a remaindered 2nd edition to save a measly $10. I mean, duh. The 3rd is a much thicker tome and although I have not compared it content-wise to the 2nd, I assume that ORA and the writers did not produce the 3rd simply to snare idiots into upgrading. If you don't already have the Camel, I don't see why you would buy the 2nd instead of the 3rd. The 2nd is great, but I can think of numerous improvements that could have made the book much more accessible.
Finally, further discussions about Perl vs. PHP vs. ASP are just plain lame... and a fair indication that the poster intends to start a religious war. Perl users like Perl for their own reasons. Others may like other things for other reasons. But since this is a book review of a Perl book, let's stick to the topic, which is not a flame war about which web scripting method is best.
I do not have a signature
I know it's been talked about before, but it seems odd to try to buy computers that have rapidly developing feature sets, such as CDRW, 3D video, USB ports, without some mechanism for the user to get the next version or three at a free or reduced cost. (Mind you, Tiger direct computerss are generally inexpensive, but this is true for all publishers).
Certainly has having used the 286 processor, I know that computers has changed a lot in 7 or so years, and much of my 286, while not fully useless, doesn't fully cover what I need to know nowadays for computing. I've been hestitent to buy the more recent computers because I see the same problem happening in another 2 or 3 years. As this review points out, some of the features on USB and 3D video when the next generation computers are released, making this computer useless.
While code morphing can easily fix this problem, that's not the solution when you need to be productive. Maybe there should be some way to 'register' the computer, such that when the n+1(th) edition comes out, you can get it for a substanially less cost, because your initial purchase of the nth edition helped to make the n+1(th) edition possible. Or one could send in the cover of the nth edition and a S&H charge to get a copy of the new computer. Or something along these lines.
If any computer book publishing company could do this, I would expect ORA to be the first to try such, given their helpfulness in the past and present. But with many standard 'things' moving so fast (XML, HTML, Perl, Python, etc), we need a some book upgrade mechanism in place ASAP.
You want to know why that statement frightens me? The same thing was said about Java. Even my mother cringes when I mention something that's written in Java; ergo, the connotation of Java translates into one word: lag.
"Ancillary does not mean you get to rule the world." --U.S. Circuit Judge Harry Edwards, speaking to the FCC's lawyer
I used to write text-processing code in basic long long ago and fell immediatly in love with Perl when I picked up the second edition of the Camel Book. It was a while before I got around to using Perl for any serverside stuff.
I'm not saying everyone will find Perl useful for everything, but it can be useful for very many things, not just server-side Slashcode.
I'm the first to admit that a serious Perl-based enterprise-level app won't be the most lightning-fast thing on the block, but I always back that statement up with it depends on how it's coded. Cheapo clients that wouldn't spring for a ColdFusion server for their sites were in no position to whine about a difference of a few seconds in process time. But I'm getting away from the point...
A programmer who knows what he's doing CAN write a viable app. Java's issues aren't in the code, they're in the VM (AFAIK).
--Just Another Pimp A$$ Perl Hacker
El riesgo vive siempre!
No offense to the people who took the time out of their lives to write slashcode, but IMHO it's a pretty bad example of a big application written in perl.
Exhibit A: when a perl file starts out with "use strict; # ha ha ha, not really" or a similar comment
Exhibit B: global hash vars used for configuration information that have names like %I (real descriptive, guys), and that are never centrally declared (ie. the components are assigned piecewise throughout a ton of different files, not one central declaration of "%I = (stuff)" in an obviously named file.) (note also that %I is not the sole conveyer of conf info, further muddying the waters)
This is not to say that slashcode is bad in terms of utility, on the contrary, the slash engine itself works quite well (as /. and any number of other slashcode sites (like the 3 I've set up) demonstrate). Heaven help you if you want look at the code though...
Like any language, a large part of it's suitability for a given task depends on the coder as well as the language's unique attributes. I've seen just as bad C and Python as I have perl.
(In the unlikely event a central slashcode maintainer reads this post: dude, try enforcing (recommending, whatever) a minimum 4 or 5 character variable name convention! It'll increase the readability (and thus ease of contribution) a good bit. :-) )
--
News for Geeks in Austin, TX
I know Tom's skills are widely heralded by many, but I'm not all that fond of his "There is ONE way to do it - my way, and nothing else, damnit!" attitude. Sure, he's a smart guy, but that doesn't make it his place to dictate how something must be done in perl, when there are perfectly good alternatives.
For instance, I recall one time when he flamed my butt off for using the OO syntax that's possible with the CGI.pm module. I pointed out that my code was perfectly valid, and no more or less valid than his "counter-example" to my code, which did not use the OO syntax. Nevermind the fact that even the docs that come with the module describe it as perfectly valid syntax.
Sure, he's a smart guy, and probably overall an asset to the perl community, but watch out for the other edge of his "sword", so to speak.
>>Although that was a long-awaited update (although it disappointed in some respects compared with the original), the differences between 5 and 5.6 do not really warrant buying a new edition. <<
At my local Perl Mongers meeting, I looked at the 3rd Ed Camel for ten minutes (I own the second). I was instantly convinced of its superiority. You may consider Unicode a minor feature, but for people who need to work in other languages than English, it's a major help. Further, Larry Wall is funny enough that a new edition (with new humor) is worth buying even if you never intend to use Perl (it helps to be a geek, tho - look in the 2nd ed. camel under the Glossary for "thread" to see what I mean).
Become a FSF associate member before the low #s are used
I have the 2nd edition, which lists Larry Wall, Tom Christiansen and Randal L. Schwartz as authors. I notice the new book has Jon Orwant in place of Randal; does this have anything to do with the past legal problems that he had experienced a while ago?
- Mike
I bought the 3rd Edition of Programming Perl, and I think it is a much-needed revision. Better organized.
Python is still replacing Perl in my work, though.
I'm going to miss CPAN, though. CPAN and Larry Wall are Perl's best features.
The only thing that we learn from history is that nobody learns anything from history.
One is the really handy 1337-speak translator. Impress your friends with how 'l337 you are! Type your regular text, run the translator and copy-paste your 1337-speak into ICQ, the Slashdot-submission boxes, a chat room, or any other web forum! See the example below!
1 4m 50 31337! 1 0wn j00! 1 g07 r007!
Similar "h4x0r" sentiments can be expressed with the same ease! Just think, no more annoying keyboard remapping! And, it's portable too! Anywhere you can install Perl, you can use your '1337-speak translator!
To order now, please have your Mastercard or Visa ready, and dial the number at the bottom of your screen. Only $19.95 plus shipping and handling.
It may look like I'm doing nothing, but I'm actively waiting for my problems to go away.
--Scott Adams
psxndc
The emacs religion: to be saved, control excess.
... "What's not to like" become "What's to consider"? Maybe when /. got into the biz of generating revenue from links to the assorted bookstores perhaps? Must not displease our corporate sponsors by insinuating that we _not_ like something in a review...
I call shenanigans _and_ wimpout on that one.. I'd not bring it up but I've seen it in the last few reviews and to my mind it's rather shady..
(kind of like stocks being rated "Buy" or "Hold".. Dammit, if you mean sell, than say "Sell"!!!)
<cult ref="JeffersonStarship">
"We built this weblog... We built this weblog on news for nerds..."
</cult>
Your Working Boy,
ASP really isn't all that bad, so long as you make sure to use JavaScript as default instead of VBScript.
Half the problem is of course the people who use a product, I knew a company where they would insist server-side stuff was done in VBS, and all client side in JS (may have been otherway round but who cares?) There reason? Their programmers were to stupid to know what was client of server side otherwise!
J-aims
--
Yo, whatever happened to peas? Join T( H)GS
30%
http://www.oreilly.com/order/upgrade.html
1--It needs to be on CD-ROM b/c commuting with it in your laptop bag sucks
2--It needs in game saves, and so does Diablo II for that matter.
This
From the time I've spent reading through the 3rd edition, I've already come away with a lot of new insights that I somehow never picked up in my 8 years of working with the language. I highly recommend the 3rd edition as the most readable and informative to date. I like the 3rd edition book far more than I do the 2nd edition, and that alone justifies the publication of the new book, Perl 6 or no Perl 6.
As for all the general flaming on Perl here, I have to say I'm a bit surprised.. Perl is still by far my favorite way of doing systems administration scripting, both on UNIX and NT. It seems like whatever I work on, a bit of Perl added to the mix Makes It Better. I can't count the number of times I have wished that /bin/sh was a Perl interpreter.. it would make bootstrapping install scripts on an arbitrary UNIX system a lot easier.
Or are people here *that* enamored of autoconf?
Anyway, best edition yet, and a damn fine job by Mssrs. Wall, Christiansen, and Orfant.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
Hm, I'll go to troll-feeding hell for this, maybe, but I have to disagree with you. I know people who have written significantly large and object-based systems in Perl, the bet-your-business kind, and it has worked out great for them. If you are a CS theory snob, I know a fellow who wrote an extensive graph theoretic analyzer for DNS data, using all the k00l algorithms and data structures. Admittedly, there were a lot of hashes involved... ;-)
It is true that a great deal of the appeal of Perl is that you can just rush in and get your hands dirty quickly and make it go, and that can seem like (and be!) messy hackwork, but so what? Like Larry says, just because you can talk baby talk and get along doesn't mean that a Milton or a Shakespeare can't get his work done in the language also.
And as others have noted, CPAN is the epitome of code re-use, and you can't get much more CS cred than that.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
You forgot one...
It may not be quite the finished product that a printed book has, but it contains all the material.
James
I love perl. Despite the current fashion for the peeps to distain it, it is a fantastic language for getting things DONE.
And I don't mean just "quick'n'dirty" stuff either; I'm talking about enterprise applications that live for a long time. I have an LDAP replication daemon, written in perl, that has been running strong for two years, thank you very much.
Perl is like English. It can be very dirty and ugly when written so, but it can also be so beautiful as to be sublime. And unlike "bondage and discipline" languages (*cough* Java *cough*) it gives you the freedom to code in an accent when needed - adapt the code to fit the problem, not the problem to fit the code!
Those that complain that perl is illegible or hard to understand just haven't seen perl written as to be maintainable - tip: don't use Slashcode as a starting point.
And as for Tom Christiansen... how horrible that there exists someone who stands up for code quality, and is willing to speak his mind!
Long Live perl!
Want to learn about race cars? Read my Book
Randal Schwartz, beyond his Perl exploits, hacked his former employer Intel, allegedly stealing passwords, and did some hacking of O'Reilly Associates. Probably politics between him and ORA, due to his lack of discretion. His, the first ORA Perl book, was enjoyable, due to his offbeat hacker humor. A less dry experience is helpful when trying to learn from a book. Then, too much humor and it can be quite frustrating. I think he provided a good balance. Randal could often be found on USENET groups, to pick his brain on various Perl problems. Always a fun guy to chat with. I wouldn't be surprised if he reads Slashdot.
--
A feeling of having made the same mistake before: Deja Foobar
My favourite exchange involving Tom and an AC on /.
:)
Do you even know anything about perl? -- AC Replying to Tom Christiansen post.
For one who is well-experienced in perl 5.005 a chapter giving info about the changes would be very useful. Please don't direct me to the CHANGES file. I want something that has been digested, similar to the way rest of the book presents the information in the perl man (or pod) pages.
Another useful section would be tips on porting scripts from 5.005 and 5.6. Not just some brush-off like "most of your scripts should run unmodified." Certainly 5.6 has corrected some things that were awkward or buggy in 5.005. What are thay so I can audit my code to take advantage of the better handling in 5.6?
Don't get me wrong - I'm one of the few people who have read Bjarne Stroustrup's "novel" from cover to cover, but if you say that someone who's done a "moderate" amount of programming such as vbscript is ok reading "programming perl" then either I'm wierd, or you're a perl expert reading a book for perl experts. Admittedly, the camel is an interesting read and a great reference, but it goes off on far too many tangents into educated matters to come anywhere near a perl beginner's resource. Rather than presenting clear examples on the knowlege learned so far, the author chooses to give complex examples on future code saying "don't worry about the bits you don't understand, I'll explain that later" which is nice, but does he expect the whole thing to suddenly just "click" a year later? Some people are less patient than that. As I say, "programming perl" is a great reference manual, but to use it for anything beyond that is silly. Even if you're an adept programmer, if you're a perl beginner, try "learning perl" or one of the other alternatives. g.
so python has in game saves?
This
Hmm. How many incorrect statements can be made in a single /. comment? This one is in the running for the record this week anyway.
1. Randal did not "hack his former employer." Randal was not an Intel employee; he was a sysadmin on contract. Those of you who have been contract sysadmins understand the issues.
2. He can and does speak for himself on this issue, but my understanding is that he was performing fairly ordinary security reviews for his then-current client. Due to what might be described as a personality conflict with another Intel person, his activities were "escalated" (insert wry telecom reference) to the point where PHB CYA mode kicked in. The company over-reacted and the matter was referred to the supine Washington County, Oregon district attorney. A Keystone Kops scenario of Randal's home being invaded by Law Enforcement Personnel, weapons drawn, ensued. Randal tried to persuade them with his notion of the truth, but it didn't matter; the CYA mode is one-way and the company felt impelled to 'accede' to the county pressing charges.
3. A show trial ensued with a judge misinterpreting both the law and the facts. Randal was convicted and received a suspended sentence and a major fine. His case is STILL ON APPEAL.
4. The lesson is here is, never forget the famous cliche "no good deed goes unpunished." Especially for those of you involved in security-related system administration. Especially when you type su
5. Hmm, come to think of it, that means all of us who manage even a single box for just one other person.
6. Randal did not "hack" ora.com. Child, where did you get these notions? Actually, I will say this, when Randal ran crack on Teleport around that time, James Deibele told him to knock it off. Then Intel and Washington County decided to throw the book at him and try to make a big bad example out of him. The way things are going it could have meant a jail sentence. As for the fine and court costs, my recollection is: $300,000. Look at those zeroes. There are a lot of them.
8. Much of the humor in the first Camel is a blend of both Larry Wall and Randal Schwartz. It remains a unique contribution to the literature of computer science.
9. "Probably politics between him and ORA." No. Read my friend Steve Silberman's piece in Wired, and you will get a much clearer view of what is going on in the Perl world. I feel very badly for Randal that after all he's done this is the kind of treatment he gets, including completely lazy, ill-informed hearsay from the likes of this 'ackthpt'.
10. "his first ORA book". No. Go read the cover, or better yet read the book. There are TWO names on the cover.
11. "I wouldn't be surprised if he reads Slashdot." You know, the Search box is your friend.
It would be so nice if everyone would engage brain before steering fingers. But this is asking for the world, I know . . .
-------
Bill Gates Is My Evil Twin.
I see your Ruby and Perl and I raise C :)
--
Ermm ... I guess ASP and JS/VBS qualifies you for the title of "webmonkey"... good luck with your new career path^H^H^H^Hbranch.
I still have to find the bloody utility of JS and VBS - aside the unofficial one - to crash the browsers.
--
do you have a link to the piece in Wired about the perl world?
Most of this documentation also comes with the ActivePerl distribution.
A good place to find some info and related links Beyond Mark Morrissey's report it's kind of boiled down to a "Did not-Did too" argument. I've not taken any side in the debate, but it is a case worth reviewing if you ever feel the urge to test security without having a job description or contract outlining that as your responsiblity.
--
A feeling of having made the same mistake before: Deja Foobar
Oh, this is rich:
"How do you formally verify a perl program for correctness?"
You compare the output to the input and the program specifications, and if the program does what it is supposed to do, it is correct.
Here's a tip from a real programmer, Java-boy: just because it *compiles* doesn't mean that it *works*
Want to learn about race cars? Read my Book