#comments

Ok, so, now that I have somewhere to vent I will at last state my extreme annoyance at the anti-perl bias so commonly found in publishing. It happens time and time again, you’re reading some book on some new fangled technothing, everything’s fine until they get to the part where they’re discussuing how the topic relates to various programming languages. Each one will get some, more or less, reasonable discussion except perl will almost always get a few snide remarks. These authors, who I’m sure work in one particular language and needed to learn just enough to write the short section on these other languages just can’t get past their hey day in the late 90’s when they discovered how cool and easy it was to bash perl. Let me take as an example the book on postgresql that I just read.

I talk about this book because I just read it and so it is fresh in my mind. The book itself was ok, if you’re really curious you can read my full review on amazon or in my blog (my 3 star review is titled “a very comprehensive book”). These authors start out with a bang:

If you are an experienced Perl programmer, you already know three things about the language: It’s extremely useful, it’s notoriously difficult to master, and it gives you a new way to write completely incomprehensible code

Don’t be fooled by that first one, one of the key elements to bashing perl is to show your unbiased view by preceeding all arguments with a quick note on how useful it is. But here we go, notoriously difficult to master? Because learning Java, C++ or .net are well known to be mastered in 21 days. Of course, a discussion of perl could never be complete without some reference to just how awwwful the code can get – because every example of PHP or TCL (both of which get no negative mention in their chapters) are shining examples of self-documenting code. That was just the warmup, let’s go on…

If you are not already a Perl programmer, you should be forewarned that I won’t try to teach you the basics of Perl programming in this chapter.

This just takes things to a whole different level. The authors’ mastery of the game is displayed here with this incredibly subtle jibe. The meaning behind this is that, Perl is so difficult to understand (unlike c, c++, java, .net, tcl and php) that if you, gentle reader, were to have simply started reading this chapter with out this warning, you’re mind might simply have exploded. All the other languages they discuss are so simple and elegant that if you read the chapter in their book, you’ll probably roll out of it with fluency in the language if not complete mastery of it.

That’s a pretty sweet introduction to the chapter. Then throughout it they work through a progression of building an increasingly functional client in perl, the same progression they use in all these language chapters. But they make this one exceptionally difficult to follow by writing code that errors out in incredibly useless ways. They spend a few pages simply on how to get DBI to connect. Rather than simply noting that DBI’s connect method takes x parameters with some of them being optional with default values, they instead write several examples where they leave out those parameters and then ask questions about why this thing could fail.. what could possibly have gone wrong? Oh ho ho, perl has done this crazy thing that if you leave out the optional parameter there is a default value that might not be the one you want! Can you believe that??

Then, they wrap that section up with a standard DBI error that the database handle is destroyed. To which they have this to say:

That’s a little better (take my word for it).

Which in a book filled with quips might have gone unnoticed, but this 1000 page tome was some seriously dry reading. The rest of the meat of the chapter progresses along those lines, although not quite as bad. They seem to have worked most of it out of their system and get on with writing normal examples. But fear not, they get the last laugh in with their summary section.

The first time I looked at a Perl program, my reaction was “that is some ugly code.” I still think Perl is an ugly language, but it sure is useful!

Ok, we’re getting back into some bashing, so don’t forget to say how useful perl is!

After reading this chapter, you may think that Perl is great for quick-and-dirty programs, but not for serious applications

Hmm, after reading this chapter, where they admit to not teaching any basics, but simply show you how to use some basic DBI commands to build a sql client (which is the same client they build in every other language) you, who have no prior perl experience, might have come to the conclusion that perl is great for quick-and-dirty programming? Uh, right. This is actually just a trick to work in this fundamental staple of classic perl bashing, no true bashing would be complete without it. So you’ll forgive them the nonsensical statement – they’re perl bashing cards might have been revoked if they hadn’t put that in. But they follow that up with:

I would disagree – like any programming language you can write incomprehensible code in Perl. But you can also write Perl scripts that are easy to understand and not too difficult to maintain

That’s a real beauty. So, you can write bad code in any language (although the authors feel no need to bring it up at any length in any other chapters). But wait, you actually can write scripts that are easy to understand and they might not be too difficult to maintain either! The implication here is that it actually would be out of the realm of possibility here to write perl code that would actually be easy to maintain.

These arguments and this type of treatment happen over and over in books of this nature. In a book with page after page of descriptive explanations of how to do things in other languages, when the writers get to perl they simply can not contain themselves. They work in all the classic arguments, they get their sly comments just so to make them appear like they are really in the know. I’m not sure why perl is the target of all these attacks, but I suppose with all the cliches around it’s an easy one to build an uninformed opinion. sigh.