Andrew L. Johnson's new Elements of Programming with Perl is titled in such close proximity to two classic texts--Strunk & White's Elements of Style and Kernighan & Plauger's Elements of Programming Style--as to beg comparison. Best not, and more is the pity.
Perl strives to be both a natural language like English and a structured language like C, but Johnson evidently does not see the value in writing a prescriptive book as the other "Elements of" authors have. Rather, he has written a review of basic Perl for the converted and initiated. But just as an inexperienced carver cannot learn good carving practice with neither a Swiss Army knife nor a chain saw, a neophyte coder cannot learn good programming with a tool that has been called the "Swiss army chain saw" of programming languages. Can anyone learn good programming style from Perl at all? Better we should learn style elsewhere and bring what we already know to the notoriously laissez-faire language.
Perl was developed by linguistic enthusiasts to model a natural language, viz., an idiom consisting of a redundant vocabulary, syntax, and grammar with flexible rules, learnable by example or trial and error. Awk programmers can convert awk scripts to Perl with a utility, then learn Perl by fathoming the output. But where is the centrality of cold, inflexible logic in the design of supportable code? The essential tension in Perl for programming beginners lies between the natural language aspects of Perl (redundancy and flexibility) and the crucial need for discipline in writing programs.
Johnson draws his hoe into this fertile terrain but ends up plowing old ground. He adopts a didactic voice and follows a predictable pedagogical path from programming illiteracy through technical proficiency. He introduces task groups--processing text, lists, input/output, modules, debugging--and stops at introductions to modules and object-oriented code.
The book is studded with examples, exercises, tips, and tricks gleaned from years of "speaking Perl," but it avoids being prescriptive, and his casual advice is sometimes disconcerting. He discusses white space in formatting code, but he breezes past error handling. He teaches recursion without warning that it is a support nightmare. Often he hides behind Perl's creed that "there is more than one way to do it" to avoid advocating what the newbies need: one better-than-average way to do it. Johnson cannot be both advocate of Perl and teacher of beginning programming, though he has tried: had his experiment been bolder, it would deserve wider attention within the Perl and computer science communities. --Peter Leopold
