Slashdot Mirror
The Perl Cookbook, 2nd Edition
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.15and 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.
One of the goals of Perl 6 is to make non-trivial projects possible. That's good. The way it's being done is bad. Perl was once a lightweight, extremely flexible language. Now it's become a huge ugly monster. People wanted OO, so a nasty hack was bolted on top to allow some semblance of it. Now this nasty hack is being expanded. Sure, the code's different, but the basic form is the same. Kludge upon kludge upon kludge; I'd much rather have a nice, clean, pure language (and not one with loads of irritating whitespace thank you very much).
The same goes for the syntax. All the switching between $, @ and % is really irritating (ask a newbie how to get at the length of the keys array of a hash inside a hash, for example), and the changes proposed for 6 are just making this worse -- it seems that Larry, in his infinite wisdom, wants to prefix every data type with a different hard-to-type character. Perl was only designed for the three data types, and adding more is a mess.
Perl 6 is a complete rewrite, but it keeps all the mess which has accumulated over the previous versions. This is not good. Sure, my const int $var = 27; may look neat (in the same way that, say, Pascal does), but $var isn't entirely constant, or entirely an integer, it's just a hack which makes it sort of behave like one. The whole thing is an exercise in pseudo-computer science masturbation with little real purpose except to please the managers who dislike the one thing that makes Perl special.
On a similar note is regexes. I'm an avid fan of regular expressions simply because a nondeterministic finite automata is far more flexible than linear code. However, Larry must have been smoking that cheap $2 crack when he wrote this. Does he want Perl 6 to be flex or something?
I won't be going on to use 6. It's a nice idea, but it's completely unnecessary. It won't make large projects any easier to manage (the language is still, at heart, an almighty hack -- an impressive one, but still a hack). It won't make OO any cleaner. It won't make development any faster. To put it bluntly, Perl scripts will still look less beautiful than our friend Mr Goatse. I'd prefer to use a language which has always been pure synthesis of science and engineering, not some half-baked imposter.
Perl 6 will be nice, but I'm guessing it will be the end of Perl. It can't do what it wants to do whilst still being based upon a nasty mess. There are now other options, which provide all of Perl's power and none of the mess. Sorry, but *BSD^H^H^H^H Perl is dying. Larry is buggering it up the ass without lubricants, just like Shoeboy is doing to Larry's daughter.
As for this:
I would completely disagree. I challenge anyone to bring forward anything for which I'm not willing to take public responsibility.