|We don't bite newbies here... much|
This could easily be a book review (in fact, it is), but it falls readily under the category "meditation" as I'm going to discuss the impact of bad books.
You can get an idea of the "quality" of the book "PERL in easy steps" by reading the blurb from the publisher's Website:
"PERL in easy steps" instructs the reader how to write Common Gateway Interface (CGI) scripts in the popular Practical Extraction & Reporting Language (PERL). These allow the exchange of data between a web browser and a web server both on Windows platforms and on Unix-based platforms, such as Linux. The book contains exciting chapters on the major features of the PERL language and there are complete example scripts that illustrate each aspect of PERL.
While that hints at the quality of this work, here are a few choice items from the book (copyright 2004!)
(There's more in my use.perl journal.)
This is probably one of the worst Perl books I have ever had the misfortune to stumble across but after my harsh review of Perl and CGI for the World Wide Web, I realized that it's terribly unfair of me to be rude to folks who have put so much effort into writing a book. In fact, Elizabeth Castro did a decent job of improving the second edition of that book, so she clearly listens to feedback. However, in comparing the first edition of the Castro book and comparing it to "PERL in easy steps", Castro's book comes off looking fairly good.
The author, Mike McGrath, of "PERL in easy steps" presents a lot of factually incorrect information and anyone trying to learn Perl from this book may conclude that Perl is garbage. If this is their only exposure, I wouldn't blame them. Books like this are a huge disservice to the language and the community and I'm embarrassed to see that books this bad are still being produced.
Fortunately, most professional programmers have learned which publishers they can trust and which they cannot. Unfortunately, those who want to learn programming don't know this and inexpensive books which promise to be "easy" are some of the first they reach for. Perl winds up getting another new programmer who writes bad code and further hurts the reputation of the language.
The underlying problem with this book is not the simplicity of the code presented. It's the quality of the code. Needless to say, the quality is very, very poor. This raises an interesting question. If we say "baby Perl is OK", why are we so harsh on baby Perl?
Years ago I stopped studying the martial arts in large part because of the hypocrisy. Martial artists would claim that the arts are about learning that you don't need to fight but they would quickly follow this up with "my sifu can kick your sifu's ass". They often wouldn't even recognize the irony when it was pointed out to them. Unfortunately, this often applies to Perl programmers. "Baby Perl" is OK but we often savage it.
There's nothing wrong with "baby" Perl. There are plenty of things wrong with "bad" Perl, but how do we distinguish them? Is it lack of "strict"? No. Removing "use strict" from an otherwise solid program does not suddenly turn it into terrible code. Using functions instead of methods is not a "bad thing". But what makes "good" baby Perl instead of "bad" baby Perl? Frankly, I'm not sure. Surely it's not fair to castigate someone for not knowing as much Perl as we would like, but when does ignorance of a better technique mean their technique is bad? That's where I'm stumped.