Slashdot Mirror
Learning Perl, 4th Ed.
Craig Maloney writes "Just about everyone out there who has ever typed #!/usr/bin/perl has encountered Learning Perl (otherwise known as "The Llama Book") in one form or another. You may have learned some of the intricacies of the language from this tome, or you've seen someone recommend this book to potential Perl programmers on-line. Learning Perl is generally in the top three recommended books for new Perl programmers, next to Programming Perl ("The Camel Book"). Now in its fourth edition, Learning Perl returns with updates covering the stable 5.8 series of Perl. The changes are subtle, but the improvements make for a clearer and more readable book." Read on for the rest of Maloney's review.
Learning Perl, Fourth Edition
author
Randal L. Schwartz, Tom Phoenix and brian d foy
pages
304
publisher
O'Reilly
rating
9
reviewer
Craig Maloney
ISBN
0596101058
summary
The fourth edition of the classic text for learning the Perl language.
When I was initially introduced to Perl, I was one of those who was recommended to read Learning Perl. I picked up the initial edition (with the mauve binding), and began my journey into Perl. What I found was a dense, hard-to-follow introduction to the language, with the experienced Perl programmer in mind. I realized that the tutelage of this experienced programmer/author might be useful, but I opted for other books instead. As others looked to me for book recommendations, I recommended other works for people looking to immerse themselves in Perl, and relegated Learning Perl to the section of my library where live books with a steep learning curve (similar to the learning curve experienced by many with Kernighan and Ritchie's classic The C Programming Language). Like The C Programming Language, however, a full grasp of the language is not achievable from texts where the central focus is to avoid using the lingo and customs of those who are more familiar with the language. Only by full immersion in the culture of the language can one become fully proficient in that language. What's new? Learning Perl 4th edition has been updated in several ways from the previous edition. The text has been updated to reflect Perl 5.8, although this book doesn't introduce any 5.8 specific concepts. The new edition was reorganized from the previous version. The chapter on Regular Expressions is enhanced, and file handles are introduced in the I/O Basics chapter. CPAN is introduced in Learning Perl, since it has become much more important to beginners. The chapter on flat-file databases (DBM/DBM Hashes) didn't make the cut for this edition, but a good portion of the chapter made its way into Chapter 9 (Processing Text with Regular Expressions). The book has a cleaner feel to it, and flows without the erratic feel of the previous editions. What's good Learning Perl could rightly be called A Tourist's Guide to the Perl Culture. The material is immersive, and teaches Perl using the verbal language of a Perl programmer. No attempt is made to dumb down the material. This leads to sentences in the book like the following: Alas, these aren't words as you and I are likely to think of them; they're those \w-type words made up of ordinary letters, digits, and underscores. The \b anchor matches at the start or end of a group of \w characters. The previous sentence makes perfect sense for those who have already grasped the fundamentals of regular expressions, but for those who aren't quite up to speed, the previous sentence warrants further study. This can be a blessing or a curse for some. Ultimately, it forces the reader to understand the Perl culture which can only improve the reader's understanding of Perl. Also of note are the footnotes. Almost every page in the book contains footnotes commenting (sometimes sarcastically) about the topic at hand. Sometimes the footnotes can be distracting, as your eyes will busily look for the next humorous footnote, such as this little gem: And /,{5}chameleon/ matches "comma comma comma comma comma chameleon". By George, that is nice. What's Bad The only complaint I can level at Learning Perl is that there could be more explanation for some of the concepts in the book. In the section called "More Regular Expressions," the book presents the following example:
What's in it for me? Learning Perl would rightly be regarded as one of the classic texts for Perl programmers to read through at least once in their Perl careers. The book is chock-full of useful information, and even experienced Perl coders would do well to at least leaf through the pages of this book for paradigms to help their coding. Absolute beginner programmers would likely find this text a little over their heads, but intermediate programmers will find Learning Perl a valuable resource in their road to proficiency with Perl. You can purchase Learning Perl, 4th 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.
When I was initially introduced to Perl, I was one of those who was recommended to read Learning Perl. I picked up the initial edition (with the mauve binding), and began my journey into Perl. What I found was a dense, hard-to-follow introduction to the language, with the experienced Perl programmer in mind. I realized that the tutelage of this experienced programmer/author might be useful, but I opted for other books instead. As others looked to me for book recommendations, I recommended other works for people looking to immerse themselves in Perl, and relegated Learning Perl to the section of my library where live books with a steep learning curve (similar to the learning curve experienced by many with Kernighan and Ritchie's classic The C Programming Language). Like The C Programming Language, however, a full grasp of the language is not achievable from texts where the central focus is to avoid using the lingo and customs of those who are more familiar with the language. Only by full immersion in the culture of the language can one become fully proficient in that language. What's new? Learning Perl 4th edition has been updated in several ways from the previous edition. The text has been updated to reflect Perl 5.8, although this book doesn't introduce any 5.8 specific concepts. The new edition was reorganized from the previous version. The chapter on Regular Expressions is enhanced, and file handles are introduced in the I/O Basics chapter. CPAN is introduced in Learning Perl, since it has become much more important to beginners. The chapter on flat-file databases (DBM/DBM Hashes) didn't make the cut for this edition, but a good portion of the chapter made its way into Chapter 9 (Processing Text with Regular Expressions). The book has a cleaner feel to it, and flows without the erratic feel of the previous editions. What's good Learning Perl could rightly be called A Tourist's Guide to the Perl Culture. The material is immersive, and teaches Perl using the verbal language of a Perl programmer. No attempt is made to dumb down the material. This leads to sentences in the book like the following: Alas, these aren't words as you and I are likely to think of them; they're those \w-type words made up of ordinary letters, digits, and underscores. The \b anchor matches at the start or end of a group of \w characters. The previous sentence makes perfect sense for those who have already grasped the fundamentals of regular expressions, but for those who aren't quite up to speed, the previous sentence warrants further study. This can be a blessing or a curse for some. Ultimately, it forces the reader to understand the Perl culture which can only improve the reader's understanding of Perl. Also of note are the footnotes. Almost every page in the book contains footnotes commenting (sometimes sarcastically) about the topic at hand. Sometimes the footnotes can be distracting, as your eyes will busily look for the next humorous footnote, such as this little gem: And /,{5}chameleon/ matches "comma comma comma comma comma chameleon". By George, that is nice. What's Bad The only complaint I can level at Learning Perl is that there could be more explanation for some of the concepts in the book. In the section called "More Regular Expressions," the book presents the following example:
Here's the text:Unfortunately the less astute reader may not understand what exactly happened here. One line of output with the end result would help clarify what this regular expression did.
I'm talking about the cartoon with Fred and Wilma!And here's a substitution to remove those tags. But what's wrong with it?
s#(.*)#$1#g;The problem is that the star is greedy. What if the text had said this instead?
I thought you said Fred and Velma, not WilmaIn that case, the pattern would match from the first to the last , leaving intact the ones in the middle of the line. Oops! Instead, we want a non-greedy quantifier. The non-greedy form of star is *?, so the substitution now looks like this:
s#(.*?)#$1#g;And it does the right thing.
What's in it for me? Learning Perl would rightly be regarded as one of the classic texts for Perl programmers to read through at least once in their Perl careers. The book is chock-full of useful information, and even experienced Perl coders would do well to at least leaf through the pages of this book for paradigms to help their coding. Absolute beginner programmers would likely find this text a little over their heads, but intermediate programmers will find Learning Perl a valuable resource in their road to proficiency with Perl. You can purchase Learning Perl, 4th 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.
Finally, a book review that's actually a review and not a summary or a novel in itself. Well done.
I've got a question. I haven't read through it yet, but I've got a borrowed copy of 4th edition. Should I bother to read through it, or should I hold out for finding a 5th ed?
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 Goat.cx. 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.
Here's the text:
I'm talking about the cartoon with Fred and Wilma!
And here's a substitution to remove those tags. But what's wrong with it?
s#(.*)#$1#g;
Uh... everything? What tags? Am I nuts, or doesn't s#(.*)#$1#g; always replace the entire string with itself? What could be more useless?
Larry is my savior.
Learning Perl is generally in the top three recommended books for new Perl programmers
The other two being this one, and this one.
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
> s#(.*?)#$1#g;
But why the cartoon swearing??
No folly is more costly than the folly of intolerant idealism. - Winston Churchill
While, ultimately, I'm reserving Perl as a skill ONLY used when absolutely necessary (ie. when I get stuck debugging someone else's code) - I didn't like Learning Perl, or Programming Perl, or Perl in a Nutshell. All three of these books left me frustrated and completely lost.
In sharp contrast, the Perl Cookbook, gave me answers to all of my questions. I recommend Perl Cookbook to anyone. The other books? Only to masochists.
These are my friends, See how they glisten. See this one shine, how he smiles in the light.
Example makes no sense.
$ echo "I'm talking about the cartoon with Fred and Wilma!" | perl -pe 's#(.*)#$1#g;'
I'm talking about the cartoon with Fred and Wilma!
$ echo "I thought you said Fred and Velma, not Wilma" | perl -pe 's#(.*?)#$1#g;';
I thought you said Fred and Velma, not Wilma
...since half the people in that room have a bind setup to spam the address of Learning Perl in response to any question,
And that's one of the reasons why Perl is heading into oblivion. Rude users. Sometimes I'll be there, a newbie will ask a newbie question, and 5 zealots will jump down their throat.
Worse then #debian sometimes, and that's hard to beat.
94% of Repubs and 21% of Dems voted to renew the Patriot Act
from the looks of it, seems like a nice book but what we need is, a book that beats people into submission so that they make READABLE perl ..
99% of the perl i look at makes me want to kill someone.. (i make sure someone else is in the room)
'...if only "Jumping to a Conclusion" was an event in the Olympics.'
What's that you say? A pedantic language that requires you to use whitespace to specify blocks and doesn't massively improve on Perl is going to replace Perl, given that many Perl programmers wouldn't bother switching because of the former reason _alone_, not to mention the fact that they're already satisfied with the ease and elegance of Perl?
== Jez ==
Do you miss Firefox? Try Pale Moon.
You can do it similarly in perl-
\d{3}-\d{4}
The reason perl implementations tend to look worse is that they try and catch other ways of writing phone numbers- removing the -, adding an area code, optional whitespace, etc.
I still have more fans than freaks. WTF is wrong with you people?
The text has been updated to reflect Perl 5.8, although this book doesn't introduce any 5.8 specific concepts.
So how exactly does this edition "reflect" Perl 5.8 then? Is is it enough just to drop a reference to 5.8 and leave it at that? This book is nothing more than a cynical O'Reilly marketing exercise. The sample chapter from O'Reilly is identical to the corresponding chapter in the 3rd edition while a brief look at the table of contents shows nothing more than a re-arrangement of the previous edition. Anyone who has the 3rd edition will be wasting their money buying this book.
Here's the text:
I'm talking about the cartoon with Fred and <BOLD>Wilma</BOLD>!
And here's a substitution to remove those tags. But what's wrong with it?
s#<BOLD>(.*)</BOLD>#$1#g;
The problem is that the star is greedy. What if the text had said this instead?
I thought you said Fred and <BOLD>Velma</BOLD>, not <BOLD>Wilma</BOLD>
In that case, the pattern would match from the first <BOLD> to the last </BOLD>, leaving intact the ones in the middle of the line. Oops! Instead, we want a non-greedy quantifier. The non-greedy form of star is *?, so the substitution now looks like this:
s#<BOLD>(.*?)</BOLD>#$1#g;
And it does the right thing.
Some may consider this a troll, but, knee-jerk reactions aside, from a professional standpoint, unless you have to maintain some legacy system that uses Perl, or an interest in historical programming languages, there is very little point in learning Perl. You can find all of its benefits in more modern non-compiled languages without the cruft of years of esoteric development. I will not mention other languages as that will just start a religious war over everyone's pet language, but, seriously, aspiring technologists take note and do your research.
If you already know Perl, that's great and good that you learned it when you learned it, but it doesn't change the above.
I joke, I joke. I have Visual Python!
Okay, I am one of those, generalists, prgrammer wannabe.
I have spent time with, C, C++, Objective-C, OCaml, Python, Java, Bash scripting, Perl, Tcl, Sql and maybe others.
And even thought Python was kind sometime, my main pick, I had to give up on it.
Python is hard, harder to learn than even C.
Learning how to program in OO, is hard, and python, regardless of what you say doesn't make it easier.
To really understand the different programming paradigm, you have to learn more than one language, an programmer who haven't look on at least 5 languages shoul question his own skills.
Anyway, Perl biggest assets in my opinion, are
- The wealth of it's literature, you can find a Perl book covering almost any programming corner and topic.
- That Perl book, will be effectively teaching you a CPAN library
Python, will never have that, mainly because no other language have that, Perl is unique in this. Plus OO programming, is just tuff to swallow, in theory, I would say OO offer a very nice level of uniformity and abstraction to any program, but in real life, it's just easier to deal with the mess of procedurla programming. And don't think of data, and behavior owners.Good luck with your Pythonic dreams, but
...just to remind me that there are things in this world less sane than C++ but oddly more seductive.
The other Perl books I keep in my private collection with my BSD books hidden behind a box of pr0n tapes and DVDs so no one thinks I'm a total perv.
If my grammar and spelling are off, I am [distracted/tired/careless] (take your pick)
Camel 4ed will likely come out after Perl6. So Camel 3ed is likely the last Perl5 edition.
I encourage you to review every article I've written there, and come to your own conclusion. I'll stand by my public record.
I am learning Perl using Beginning Perl
And I am really satisfied with it, it's free, it's comprehensive and it's author is a skilled Perl hacker.
I would like to know, what more does Learning Perl have to offer? (For one it's not free!)
If it's depth, I plan to use the perldoc and perlmonks.org for the depth. And beginning perl just for the big picture (not that it doesn't offer depth, it does to a great degree).
With respect to Rasmus, whom I've met on more than one occasion, I've often said:
I'll leave it to you to discover why I say that.I just read the last 40 posts of one Mr Randal L. Schwartz on PerlMonks as per his link here and found none to be aggressive or unprofessional and instead helpful if not patient. Sorry AC you must have some axe to grind.
The reason I use and recommend perl over other languages is the useful INDEXED source of common modules called cpan.
This single resource has saved me many hours of programming alone. More than pays for some of the obscure problems. Frankly it is up to the programmer to write good code, not the programming language. I can show you horrible code in about 20 different languages from Cobol to C to Java to Perl. Learn how to write and comment clearly and any language is a good language.
PHP being more secure than perl. You're joking right?
b m=%2F&submit=Search!&metaname=alldoc&sort=swishran k
Where's PHP's equivalent of perl's taint mode? Where's the PHP's equivalent of perl's "use warnings" and "use strict"? Where's PHP's equivalent of DBI's parameterised queries?
And have you seen the amount of entries for PHP on bugtraq: http://www.securityfocus.com/swsearch?query=php&s
http://www.perthonline.net
Perl was never designed for the web. PHP was designed from the ground up to be a web scripting language. As such, it blows the doors off of Perl in terms of speed, funtionality, ease-of-use, deployment, understanding and security. PERIOD.
:-)
./
Except, no, it doesn't. PHP is not faster. Most people say this when what they mean is that PHP has a smaller memory footprint, and can therefore handle more connections on a given machine. I will grant this, but we have no problem adding more hardware, as it is a negligble cost in the grand scheme of things.
Functionality? Are you kidding? There's nothing PHP can do that Perl can't, but Perl can do much PHP can't.
Ease-of-use, deployment, and understanding are in the eye of the beholder. I understand Perl quite well, thanks very much. That (hypothetical) you don't puts no obligation on me to stop using Perl.
As to security: why is it that we are almost constantly seeing CSS and other vulnerabilities for Slash-a-likes written in PHP, but almost never see the same for Slash itself, which is written in Perl? Granted, it could be that PHP is more secure but Slash's programmers are just superior.
But Slashdot is an uber minority when it comes to selecting Perl as the real-time scripting language to use on the web. They've done a fine job, but if the application were written in PHP instead of Perl, it would likely perform twice as fast.
Thank you. But no, it likely would not be faster, since the bottleneck is not Perl, but the database. You might contend that if we wrote it in PHP, it would take fewer machines to get handle the same number of queries, but that would mean using a language that we like less, are less familiar with, and which has a whole host of problems with functionality that we'd have to spend more time (read: money) to work around.
only crazy people use it in high-traffic, mission critical, real-time enviroments like
People keep saying that as if the facts -- for both Slashdot and LiveJournal, as well as others -- don't absolutely refute the statement.
Disclaimer: I'm not a PHP programmer, the above is just what I think happens. :)
Of course, none of this matters for a big site like slashdot, or the ones I develop. But for small people who are just "playing around", it can be a big inhibitor. And that's one reason why I think mod_perl has lost mindset to PHP in the past.
-Dom