Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Perl Books Media Programming Book Reviews IT Technology

The Perl Cookbook, 2nd Edition 148

Posted by timothy from the who's-cooking-tonight dept.
doom writes "For those of you who haven't been paying attention, when the The Perl Cookbook by Tom Christiansen & Nathan Torkington came out in 1999 it immediately became one of the primary references in the perl world. It's one of the first places you should check before making a move with perl, right up there with search.cpan.org, itself. Now we've got the second edition. What's the diff? The diff is 58 new recipes and program examples (list provided below), plus two new chapters on mod_perl and XML (which provide an additional 27)." Read on for doom's complete review.
The Perl Cookbook, 2nd Edition
author Tom Christiansen & Nathan Torkington
pages 927
publisher O' Reilly
rating 9
reviewer doom
ISBN 0596003137
summary How to do common tasks in perl

The new recipes cover a number of subjects. One of the prominent themes is how to use perl's new unicode support, as well as the new I/O layers feature. The coverage of web programming has definitely been fleshed out with recipes on XML-RPC, SOAP and so on, plus the new chapter on mod_perl. Also of interest of course are the additional recipes on database access with DBI.

The mod_perl chapter is a good succinct introduction, with some very cute recipes in it (though admittedly a lot of these are also covered in the excellent Mod_perl Developer's Cookbook by Young, Lindner and Kobes out from Sams). For example "Transparently Storing Information in URLs" shows how to embed information in any arbitrary position inside a URL. This quickly shows the kind of things you can do with a PerlTransHandler and a PerlFixupHandler. The chapter closes with what looks like a good introduction to "Template Toolkit", which I would probably be very excited about if I wasn't already familiar with the (also discussed) HTML::Mason.

I really enjoyed reading the XML chapter (a subject I'm less familiar with): I predict that you'll find this to be the fastest way through the XALPHABET XSOUP without drowning. For me, this was almost worth the price of the book.

Very little has been removed (hence the page count has gone from 757 to 927), and where I have been able to find a deletion, there are usually very good reasons for it. For example, the first edition takes the trouble to tell us that qr// was introduced in perl 5.005, but the new edition drops the babble about versions there, because for most of us, anything before 5.6 is now ancient history. However, I do miss this particular irrelevant parenthetic aside that's been deleted now:

Remember that the opposite of
read is not write but print, although oddly enough, the opposite of sysread actually is syswrite. (split and join are opposites, but there's no speak to match listen, no resurrect for kill, and no curse for bless.)
(p.295, first edition, compare to p.323, second edition.)

In general, it's difficult to think of anything seriously wrong with the Perl Cookbook. I might suggest that in some places they fall into the trap of talking about all the ways to do it, rather than just the best ways, (e.g. recipe 7.5 "Storing Filehandles into Variables" seems a bit complicated).

And maybe there are some slight problems with order of presentation, as with the new perl 5.8 feature of "I/O Layers", which is mentioned a few times before it's finally discussed in the beginning of Chapter 8 (though really, it's amazing that there aren't more problems like this: this is supposed to be reference work, and yet it usually works well as a tutorial also).

I've got one big complaint about the 2nd edition though: they changed the numbering of existing recipes! I've been writing code with comments like

# Schwartzian transform. See Perl Cookbook, recipe 4.15
and now it turns out I should've been specifying an edition number also. Please: "Cookbook" authors, come up with a numbering scheme that remains invariant with new editions... if you can't always just append to the end of the chapter, there's nothing wrong with tacking another dotted decimal on the end. We're programmers, we can handle it.

And speaking of the "Schwartzian transform" that recipe has a very clear, self-explanatory name "Sorting a List by Computable Field", but in the first edition, there was also a footnote explaining that many people call this the Schwartzian Transform, named after Randall Schwartz, who invented the technique. With this second edition, that footnote has been quietly dropped. Guys, if you're going to carry on a feud, this is really not the way to do it. It just makes you look bad.

O'Reilly's perl.com site has a series of articles by the authors, featuring some recipes from the book:

Appendix: New recipes and examples (not including the two new chapters):

  • Using Named Unicode Characters
  • Treating Unicode Combined Characters as Single Characters
  • Canonicalizing Strings with Unicode Combined Characters
  • Treating a Unicode String as Octets
  • Properly Capitalizing a Title or Headline
  • Constant Variables
  • Implementing a Sparse Array
  • Creating a Hash with Immutable Keys or Values
  • Matching Nested Patterns
  • Writing a Subroutine That Takes Filehandles as Built-ins Do
  • Storing Multiple Files in the DATA Area
  • Reading an Entire Line Without Blocking
  • Treating a File as an Array
  • Setting the Default I/O Layers
  • Reading or Writing Unicode from a Filehandle
  • Converting Microsoft Text Files into Unicode
  • Comparing the Contents of Two Files
  • Pretending a String Is a File
  • Working with Symbolic File Permissions Instead of Octal Values
  • Writing a Switch Statement
  • Coping with Circular Data Structures Using Weak References
  • Program: Outlines
  • Overriding a Built-in Function in All Packages
  • Customizing Warnings
  • Writing Extensions in C with Inline::C
  • Cloning Constructors
  • Copy Constructors
  • Saving Query Results to Excel or CSV
  • Escaping Quotes
  • Dealing with Database Errors
  • Repeating Queries Efficiently
  • Building Queries Programmatically
  • Finding the Number of Rows Returned by a Query
  • Using Transactions
  • Viewing Data One Page at a Time
  • Querying a CSV File with SQL
  • Using SQL Without a Database Server
  • Graphing Data
  • Thumbnailing Images
  • Adding Text to an Image
  • Program: graphbox
  • Turning Signals into Fatal Errors
  • Multitasking Server with Threads
  • Writing a Multitasking Server with POE
  • Accessing an LDAP Server
  • Sending Attachments in Mail
  • Extracting Attachments from Mail
  • Writing an XML-RPC Server
  • Writing an XML-RPC Client
  • Writing a SOAP Server
  • Writing a SOAP Client
  • Program: rfrm
  • Using Cookies
  • Fetching Password-Protected Pages
  • Fetching https:// Web Pages
  • Resuming an HTTP GET
  • Parsing HTML
  • Extracting Table Data

You can purchase The Perl Cookbook, 2nd Edition from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
This discussion has been archived. No new comments can be posted.

The Perl Cookbook, 2nd Edition More

The Perl Cookbook, 2nd Edition

Comments Filter:

  • same price and free shipping (Score:1, Informative)

    by Anonymous Coward
    Referral: Amazon has this book for the same price as bn and with free shipping [amazon.com]

  • Doesn't work for Perl 6 though... (Score:4, Informative)

    by i_want_you_to_throw_ ( 559379 ) * on Tuesday October 14, 2003 @12:54PM (#7211088) Journal
    The second edition works great for Perl 5.8. but not for Perl 6 which is going to require a rewrite of ALL of the Perl books.

    O'Reilly addresses the issue here [oreilly.com]

    Still Perl is such a beautiful thing you should buy ALL Perl books.
    • Doood, Perl 6 is still in its design phase. No interpreter yet; of course this cookbook has nothing on it...

    • ...you should buy ALL Perl books

      But the bookshelf can't take any more! Seriously speaking, my O'Reilly shelf is packed, 15 volumes at work (not just Perl), and I think I have more stashed at home.

      Makes me wonder though if anyone out there has a huge O'Reilly collection. Or does everyone migrate to CDs...

    • Correction:

      Still Perl is such a beautiful thing you should buy ALL O'Reilley Perl books.

      The O'reilley books are excellent. They are written by some of the major coders for perl like Larry Wall, Tom Christiansen, and David Swartz (I think thats his name).

      They are informative and fun to read because of the humor and relevant info that are in the books. I have a copy of the 1st edition of the Perl Cookbook, and it is probably my favorite programming book that I own, and I would imagine that I'll be gett

    • What you say is true for Perl 6 the language, but not perl 6 the interpreter.

      My understanding is that the perl 6 interpreter, despite being a ground-up rewrite, will run Perl 5.x scripts perfectly well.

      From what I can gather, the perl6 interpreter will consist of a sort of 'meta-interpreter' (Parrot), plus modules that tell it how to interpret a particular language. The interpreter will automatically detect which language (and which variant of the language) you are trying to use. So you could, in princi

  • But.. (Score:1, Troll)

    by rf0 ( 159958 )
    It doesn't tell you how to build the kitchen sink

    Rus

  • How do you test Unicode? (Score:5, Interesting)

    by GGardner ( 97375 ) on Tuesday October 14, 2003 @12:56PM (#7211119)
    So, I've got perl scripts which may need to work on Unicode and non-ascii character sets somtime in the future. Today, I just test them with UTF-8, and it seems to work, but who knows if they really do work on those funny character sets? I can't read Kanji or other non-ascii characters. How can I test to see if they do work? Ideally, I'd like to have an xterm-like window that uses my standard keyboard to generate analogs to all my ASCII characters, but with some test encoding that puts them into some 16 bit character set range. This way, I can make sure that since we've gone to all this work to add Unicode support into our scripting languages that it does indeed work. Does anyone know how to test this?
    • The way to do this is to use the CPAN modules Test::Harness, CharacterSets::Unicode, CharacterSets::Kanji, CharacterSets::UTF8, WideChars::ASCII, WideChars::Unicode, WideChars::UTF8, PerlCore::NonASCII, PerlCore::FuturePerl, Term::XTermLikeWindow, PerlCore::Language::Scripting, Standard::Keyboard::Generate::Analogs::ASCII, and of course, Add::Unicode::Support::Into::Our::Scripting::Langu ages::That::Does::Indeed::Work

  • ...now it turns out I should've been specifying an edition number also.

    Why not do this in the first place? Anyone who's written a university essay knows the importance of edition numbers. Page-numbering is particularly vulnerable, since even small clarifications will shift things around.

    A different, and likely just as effecitive alternative, is to not specify the recipe number at all. Surely there's an index where you could look up "Schwartzian transform" without hard-coding the number.

  • Perl is like sex (Score:4, Funny)

    by Anonymous Coward on Tuesday October 14, 2003 @01:06PM (#7211240)
    • It's easy enough to get started, but takes years to get really good
    • Doing it fast doesn't mean doing it well
    • It's the little details that continue to amaze you
    • You don't learn it from a book
    Remember to actually use perl if you want to experience the bliss of perl.
    • A.C. you forgot the most important likeness:

      THERE IS MORE THAN ONE WAY TO DO IT!

    • Doing it fast doesn't mean doing it well
      However, sometimes a quicky is all you need.

    • how about

      It can get messy

      If you aren't careful, you end up with a little monster you wish you had aborted before it got too big

      • It's easy enough to get started, but takes years to get really good
      • Doing it fast doesn't mean doing it well
      • It's the little details that continue to amaze you
      • You don't learn it from a book

      On the other hand, also like sex, it won't take as many years to get really good if you do bother to read some well-written books on the subject. Perl books tend not to have as many pictures, though.

    • And there's a Kama Sutra available for it: Larry Wall's Programming Perl, which has the subtitle "There's More Than One Way To Do It".

      This is the Fucking Manual, everybody tells you to read when you ask stupid questions.
    • And, in addition to the obvious TIMTOWTDI, what's beautiful to one may be ugly to another.

      And the most enjoyable similarity: If you get curious, you can always try it in private with a trusted partner! (Uh, does the computer count as a partner?)
    • I agree, but for different reasons:

      It isn't easy to get started, and most people only do enough to get finished quickly.

      Even if you are extremely careful you'll probably end up with a big mess.

      If you look at Perl long enough, you wish you'd done it with something else.

      You and your partner are fantasizing about better equipment (Python) and/or gemstones (Ruby).

      It can be constantly interrupted by poorly constructed arguments and (de)referencing past mistakes

      It doesn't scale well beyond two developers.

  • perldoc.com (Score:2, Informative)

    by scoobydo ( 690110 )
    I have found www.perldoc.com quite useful for multiple versions of perl.
  • I haven't bought a technical book since I have moved out of the States - O'Reilly's Safari has been nice for that. I can still have access to their books.

    I haven't looked to see if this new one is on there yet - I have the old version of it in paperback form as I do with pretty much all the other O'Reilly Perl books.

  • Very little has been removed (hence the page count has gone from 757 to 927), and where I have been able to find a deletion, there are usually very good reasons for it.

    Correct me if I am wrong but I seem to remember that the first edition had quite a few errors (both syntactic and semantic). I'm guessing that the second edition has cleared all these up. However, when I try to access the errata for the first edition I can't find it! Surely support for previous editions doesn't "end" upon publication of
    • I found this to be the case as well. That has to be a huge pet peeve with me. Any technical book that has source code listed should be proofed. There is a C++ book out there that I just got done reading and there was source code listed that wouldn't even compile due to forgetting include statements or leaving out a bracket or semicolon. You would think the authors or a proofing team would at least try to compile the code that was in the edition!

      I agree with another post. PHP, Python, and other ways to go

      • If you find PHP to be head and shoulders above anything, let alone Perl, you're nuts. PHPs broken Array/Hash implementation reeks and it's got a million inconsistencies where in most cases something works one way, in the other 5% it picks a random way to operate.

        PHP is the driving force behind mod_perl. It's great for small to medium stuff but I'd hate to write something big in PHP. (At least, where the guts are in the PHP - if it was only for templating it would be okay.)

  • Know the index... (Score:2, Informative)

    by jargoone ( 166102 )
    of the cookbook. Hell, keep the electronic version in a text file somewhere. There have been at least a couple of times I've finished writing a script, then I've looked in the Cookbook and found a better-written solution.

    It's unique in that it doesn't just tell you about specific language properties. It actually gives a problem, a solution, and an explanation.
  • The Perl Cookbook is one of the top three technical books I've purchased. If the new version improves on the old version, it is a must-have for anyone who does anything with Perl.

    Regardless of the religious wars over languages, I have time and again found Perl to simply be the most practical language for the job and continue to enjoy using it for a variety of tasks and watching it mature.

    There is no substitute for the CPAN [cpan.org] or Perl's ability to get the job done quickly and easily with an active communit [perlmonks.org]

  • Schwartzian Transform (Score:4, Informative)

    by gnat ( 1960 ) on Tuesday October 14, 2003 @01:35PM (#7211614)
    Was it dropped because of a feud? It's great to be told why I do things :-) I don't remember it that way. The bit we deleted was just not a very useful observation. As you can tell, we tended to drop the parenthetical asides (when we remembered) to try and prevent bloat. My biggest fear was that we'd break 1k pages in this edition ...

    But I guess it's convenient to think of everything that happens as being the result of a feud and ignore inconvenient facts like the "Schwartzian Transform" name still being mentioned in the long entry on sort function in Programming Perl, 3ed, which Tom also cowrote. Hmm, maybe I shouldn't point that out--now I'll be accused of having a feud with Randal!

    --Nat

    • gnat responded:
      Was it dropped because of a feud? It's great to be told why I do things :-) I don't remember it that way. The bit we deleted was just not a very useful observation. As you can tell, we tended to drop the parenthetical asides (when we remembered) [...]
      Well okay, this is a case where I'm happy to hear that I'm wrong. My apologies.

  • XML Chapter (Score:3, Interesting)

    by gnat ( 1960 ) on Tuesday October 14, 2003 @01:46PM (#7211780)
    Thanks! In a testament to the power of caffeine and good friends, that chapter came together in the space of about four nights. I'd work regular business hours doing editing, then at 9 or 10pm I'd write the XML chapter. I got great feedback and clarifications from Matt Sergeant, Dan Brian, Michel Rodriguez, Adam Turoff, Robin Berjon, and other such Perl XML luminaries.

    As you would have guessed if you heard me speak in 2000 [frii.com], I'm not the biggest XML user. I've mellowed since then, but I still don't do a lot of XML hacking. (One of the spare-time hacking things I've while here at O'Reilly, though, is to get our internal database of "what books are at what stage" into XML for easy grepping and reuse).

    Of all my work in the 2nd edition of the Cookbook, the XML chapter is the one I'm proudest of. I'm really glad you like it. Thanks!

    --Nat

    • gnat wrote:

      Thanks! In a testament to the power of caffeine and good friends, that chapter came together in the space of about four nights. I'd work regular business hours doing editing, then at 9 or 10pm I'd write the XML chapter. I got great feedback and clarifications from Matt Sergeant, Dan Brian, Michel Rodriguez, Adam Turoff, Robin Berjon, and other such Perl XML luminaries.

      As you would have guessed if you heard me speak in 2000 [frii.com], I'm not the biggest XML user. I've mellowed since then,

  • I've worked as a Perl programmer for several years, and the only book I've ever needed is "PERL - from the ground up" by Michael McMillan.

    It has among others a very handy reference to Perl's built-in functions, lots of regexp stuff and more.

    For everything else there is www.

  • Christiansen on /. (Score:1, Offtopic)

    by craw ( 6958 )
    FYI. Tom Christiansen (54829) used to post comments here. He stopped because of the crap associated with the story [slashdot.org] on the death of Richard Stevens. Search for Christiansen to read his parting words.

    IIRC, then came karma.
    • Yes Tom's post is worth reading again. I have several of Stevens (and Tom's including the aforementioned) books sitting on my shelf. It is too bad that the moderation system does not do a better job of filtering out the stupid, immature and souless comments more efficiently.

    • Interesting. I hadn't heard much about W. Richard Stevens before then...and it's funny, the negative comments were modded down to hell, just leaving a lot of people pointing out the ignorance and unseemliness of the negative comments. Seemed like a strong case of "a few bad apples".

      Actually, I'm always a little amazed that any "big names" show up here, and then I'm amazed that I find that amazing.

      Feh, I wish I had gotten my username here when I started reating, instead of a year or two after. I'd have an
      • Right now, Bruce Perens seems to be the "biggest name" that posts comments here. I remember a few from Rob Pegoraro, who is a tech columnist for the Washington Post. Somebody from abcnews.com also use to post a few comments.

        A long time ago, /. ran an interview of one of the lead developers for some OS project. Perusing the comments to the story, I ran across a "First Post!" that was modded up to +5 Funny. Huh? Oh, it was the interviewee! Absolutely hilarious.
    • ....But I can personally attest that Christiansen can be such a jerk that he can't even be approached when he is positively wrong. I pointed out a very specific bug in Perl back in the Perl 4 days which had not been fixed for weeks to him. He said it had been fixed and that I was a fuckwit for bringing it up again. Gave him code to show I could still do it. He called me a liar. I appealed to higher gods. He caught wind. Then started a campaign to squash me on comp.lang.perl.misc. That worked because of his
  • The first edition was an essential purchase for me, but I find that I refer to the HTML version on the 'Perl CD Bookshelf' much more often than the paperback. Anyone who doesn't subscribe to Safari and wants to read the electronic edition of Cookbook 2 will have to wait until January, when it'll be included in the 4th edition [oreilly.com] of the Bookshelf.
  • I'm rather partial to R. Schwartz's books on the topic, the "pearl" book, the "camel" book -- I've never been a fan of tchrist and the documentation he writes. I secretly suspect him of authoring the awful OOP chapter in the Camel book.

    Back in the day the venerable "Perl 5 HOWTO" was the shizzy for doing stuff before there was a billion modules in CPAN to do pretty much everything. I still refer to it when I need to write a server from scratch, even though its probably five years out of date now.

    To the
  • I found one issue with it as a newcomer to Perl, not immediately familiar with the various datastructures and methods of doing things: it stressed reliance on external libraries at the expense of learning other ways to do it.

    Sure, Laziness is a virtue and all that, but to cite a specific example, I looked up how to parse program options. All Cookbook has to say on the matter is to use GetOpt. This is fine, and is decent advice, until you realize that GetOpt is by no means a complete solution, as it doesn'

  • Guys, if you're going to carry on a feud, this is really not the way to do it. It just makes you look bad.
    Please, let's be clear. This little spat that Tom has about me is completely one-sided. I get a bit pissy when I have to play defense, but otherwise, it's entirely about Tom attacking me. I have nothing against him otherwise.

Slashdot Top Deals

An adequate bootstrap is a contradiction in terms.

Close