Book Reviews

The following book reviews are the copyright of their respective authors and no part should be reproduced without the express permission of the author. Publishers and Authors of the books reviewed may reproduce the whole or extracts of a review for their book. To request copyright permission please email webmaster@birmingham.pm.org.

All the reviews herein are the opinions of the reviewer and are not necessarily the views of Birmingham Perl Mongers and its members. If you feel a review or comment has been made in error, please contact webmaster@birmingham.pm.org to rectify the situation.

Perl Books

Static Link: http://birmingham.pm.org/reviews/43

 
Perl Developer's Dictonary
Title:Perl Developer's Dictonary
Author(s):Clinton Pierce
ISBN:0-672-32067-3
Publisher:Sams
Reviewer:Brian McCauley

My first impression of this book is that the style is, on the whole, clear and readable, and the examples are also clear and helpful. It basically covers the same material in the same depth as any Perl reference manual. The book is not, and does not claim to be, a tutorial and if you tried to use it as such you'd find that the order in which concepts are introduced surprising - most people wouldn't get around to code references, labels and version strings until after introducing subroutines.

Calling itself a dictionary, the book is not an alphabetical reference, but could be a serviceable reference manual, if it were not let down by a very weak index. The index works if you are looking up a Perl function or a Perl concept by the author's chosen name. But if you want to find out about GLOBs you'll not find them by looking up "glob", but rather you'll have to lookup the pedantically correct but less widely used "typeglob". If you want to find out about an abstract concept such as how to do a set union operation in Perl you are really stuck. The explanation of tainting can only be found by looking up the <CODE>-T</code> switch and not the word "taint".

Cross linking between sections ("see also") is not as extensive as I would like. For example there is no mention of the <CODE>qr//</code> construct in the explanation of the <CODE>/o</code> regex qualifier. Similarly the example of <CODE>#line</code>, <CODE>__FILE__</code> and <CODE>__LINE__</code> should mention <CODE>eval()</code> as this is the main time it's useful. (Most people don't get involved in using preprocessors). These examples are not atypical for the book.

More significantly, in these days when we are used to the instant gratification of the hyperlink, it is outrageously annoying to have to do a double look-up to follow cross-references - they could at least have included page numbers!

Examples often unnecessarily use features that are not related to the current topic and could cause inexperienced programmers to pick up bad habits. For example, in the example for the use of <CODE>quotemeta()</code> the <CODE>/o</code> regex qualifier is used with no explanation of what it does. In this particular case it's harmless, but many new Perl programmers become far too keen on using <CODE>/o</code> on every regex in their code, without realizing that it will cause problems if the program is subsequently changed such that the code in question is called repeatedly with different patterns. Similarly many examples use alternate delimiter characters on the match operator for no good reason.

It would be good if examples used <CODE>my()</code> more. In a well-written real Perl program very few assignments (except ones to elements of aggregates) would lack a <CODE>my</code>. It seems odd that programming examples in many books fail to reflect this. Worse still in many examples in this book even variables used within subroutines are not localized in any way - neither lexically nor dynamically. The initial introduction to variables doesn't even mention lexical scope. Late introduction of lexical variables is, IMNSHO, a bad affectation often found in Perl books that have been inappropriately influenced by the fact that <CODE>my()</code> appeared late on in the history of Perl.

The final nail in the coffin of this book is the poor proof-reading. There are just too many trivial mistakes (see appendix below) for one to have confidence in this as a reference.

So despite my initial positive impressions of this book, I'm afraid I would have grave misgivings about recommending the current edition of this book. Hopefully a second edition will appear soon with corrections.

Appendix - errors

I have not read the whole book. I have read up to page 100 and dipped into the rest at random. I found errors, on average, every few pages. In this I am counting anything that is misleading, factually incorrect or omits important information that could cause the reader to adopt bad practices. The following are the errors I have found.

p12 The URL of perlmongers is wrong.
p19 <CODE>sperl</code> called on a non-suid script gives an error.
p24 For a Perl scalar, being dual-valued in not the same thing as being magic. <CODE>$!</code> is both.
p27 The typeface of <CODE>n</code> used as a metasyntactic variable in <CODE>$array[n]</code> is not distinguished from the rest of the text.
p31 "Perl assumes that hash keys are simple strings, but will do interpolation within the curly braces". What is this supposed to mean? It appears to be saying that the braces of a hash subscript are double-quotish. They are not.
p32 Explanation of a hash used in a scalar context doesn't explain that an empty hash will return a false value in a Boolean context.
p41 When talking of a constructor called with two arguments, the book says "new() will receive two arguments in @_". No it bloody won't - it gets three.
p41 "Anonymous [aggregates] are simply [aggregates] with a reference count of 1". I think this is confusing. They are in effect more like aggregates with a reference count of zero - until you store the reference to them somewhere.
p42 Section on circular references should contain at least a "see also" mentioning weak references. In fact weak references are not even mentioned in the index so probably don't appear in the book.
p51 The example used the <CODE>/o</code> regex qualifier without explaining it. This is indeed one of the very rare cases where it helps, but the program would run OK without it and this is a big problem with people over-using <CODE>/o</code>.
p54 "A block is [...] a loop that executes exactly once". No, that's just bare blocks, as correctly explained on p56.
p55 I think "undocumented" is too mild a word for the behavior of the "<CODE>my if 0;</code>" construct. The behavior is undefined.
p58 The "Usage" of <CODE>sub</code> implies anonymous subroutines can't have attributes and prototypes. They can even though these aren't much use unless you subsequently put the subroutine into the symbol table.
p62 The magical <CODE>while(<>)</code> does not create a new dynamic scope for <CODE>$_</code>.
p62 The <CODE>for(LIST)</code> loop syntax does not do assignment to <CODE>$_</code> (it does aliasing).
p64 Monspaced typeface of the word "lexical" in the section heading implies that it is a reserved word in Perl. It isn't.
p65 Not all pragmas are lexically scoped.
p71 Does not warn of the counterintuitive interaction between the <CODE>package</code> directive and <CODE>our()</code> declarations.
p75 The reserve word <CODE>wantarray</code> is one word.
p75 <CODE>POSIX:_exit</code> should read <CODE>POSIX::_exit</code>.
p80 If the loop control variable of <CODE>for</code> is already lexically scoped, it is implicitly redeclared as a new lexical within the loop scope as if you had specified <CODE>my</code> in the <CODE>for</code> statement.
p80 "assignment-and-localization" should read "aliasing-and-localization" and the example of the one-element loop should therefore come after the explanation of the aliasing.
p84 Description of the <CODE>while</code> statement modifier does not mention the special case for <CODE>do{}</code>.
p82 Redundant <CODE>local($_)</code> before a <CODE>for(LIST)</code> which does an implicit one anyhow.
p99 In the list of zero-but-true constants the widely used <CODE>'0E0'</code> value is not mentioned.
p261 <CODE>eval()</code> example to unroll a loop does not warn about the dangers of special characters in data.
p293 The book states that the sequence <CODE>2</code> in a regex will be interpreted as either a back-reference or as ASCII 2 depending upon whether or not there are two or more captures in the regex. It then immediately contradicts this and says it will always be interpreted as a back-reference.
p300 "... with the {min,max} searches, the match will absorb only as many characters as necessary and still have the match succeed." This wrongly implies that the quantifier is non-greedy. The word "necessary" should read "possible".
p304 The regex <CODE>/(?i:the)/</code> is equivalent to <CODE>/[Tt][Hh][Ee]/</code> not <CODE>/[Tt]he/</code>.
p312 Description of the <CODE>$</code> regex anchor does not explain its behavior with respect to newline characters.
p313 In the description of <CODE>B</code> it states, "B matches between W and W characters; thus BFOO will find FOO but only if it's preceded by a word character". Whilst it is true that <CODE>B</code> will match between <CODE>W</code> and <CODE>W</code> characters, in this example <CODE>B</code> matches between <CODE>w</code> and <CODE>w</code> characters.
p316 Description of the <CODE>/o</code> regex modifier does not advise to see also the <CODE>qr//</code> operator.
p318 The use of <CODE>$foo=~$bar</code> (implicit match operator) versus <CODE>$foo=~/$bar/</code> (explicit match operator) will make no difference to the speed as they compile to the same thing.
p342 In the example of using the comma operator to propagate taint <CODE>$r=$c,$r;</code> should read <CODE>$r=($c,$r);</code>

Brian McCauley, 2004-05-12