31 of 37 people found the following review helpful
By A Customer
This review is from: Learning Perl, Third Edition (Paperback)
I hate to slam a book that is considered such an essential book in the community. But I feel compelled.
First, the good points: It has great reference sections. Very, very important for such a book. It is also reasonably comprehensive. Sure, you'll probably also want Perl Cookbook to really know what you are doing, but it's too much to ask for Learning Perl to contain such practical uses. It crams so much more in than most programming books.
As for the bad, I could rant for a long time, but I will try to be brief. First, the book's organization leaves much to be desired. While the macro-organization is perhaps reasonable enough, a trial lawyer would have a field day with the objection, "Facts assumed not in evidence." There are numerous code snippets in this book that are only understandable at even the most basic level by flipping ahead 100 pages, then cross-referencing to the appendix and then flipping back to a different chapter. A novice programmer shouldn't have to deal with terms like "grep" or the like until the definition of "grep" is actually given since, after all, the last time I checked, "grep" was not a standard phrase in the English language that is understandable to all.
The book is written for people with a broad background in programming. For example, the reference section, which is supposed to describe the functions in depth describes how the command "printf" works as follows: "This is similar to the C library's printf(3) and fprintf(3) functions." While there was some other gobbledygook in his listing, none of the gobbledygook explained how the function worked. Last time I checked, the book was titled Programming Perl, not Programming C, Volume II. Why its only description for how the function actually works is a reference to another language is typical of the breezy arrogance of the authors. This was more egregious than most other examples, but in general, the authors were telling their story to insiders who needed a refresher course, not people who wanted to hear the story from the beginning.
In retrospect, after reading other books about programming, most horrifying to me is the utter lack of disregard for good programming standards at the most basic level. The authors seem to glorify the "Obfuscated Perl" approach, which is to write the language in as tightly wound and obfuscated a way as possible. This is simply bad programming, even it does take a very smart person to understand what's going on.
Ideally, good code should be readable like a novel, if you have a basic understanding of the language. In a good novel, you don't flip back and forth between pages trying to remember who or what something was. Variables and subroutines should have clear, unambiguous names. Variables should be clearly spelled out, as opposed to the way the authors (and most Perl programmers) seem to think is best, which is to refer to such constructs as $_, requiring one to flip pages to where the subroutine was called to understand what information is being passed to the the subroutine.
Rather than taking the attitude -- almost universally held in the Perl community -- that There Is More Than One Way To Do It, the authors should have emphasized, You Might Want To Think About The Option That Will Make It Easier For You And Others To Understand Your Code When You Look At It 3 Months From Now. Journalists don't score points for writing obscure text. Yes, they can write things any way they like, but they have professional standards - codified in the AP Style Guide, among other places - that say that certain ways of doing things are better for readers. Programmers should adopt a similar way of thinking - both about the readibility and workability of code -and this book does everything to undermine this notion.