The Perl You Need to Know Part 22: Warts and All - Page 160

This month we get negative, putting a big mirror up to the camel that is Perl, and taking stock of its lumps. It's only fair. As a Perl developer, you benefit from knowing not only the strengths and capabilities of a programming language, but also its limitations. As in people, flaws are a subjective thing. What some might consider a flaw, others may tolerate, or even celebrate. This look at Perl's flaws is therefore necessarily subjective — some may disagree, and they, like everyone, have the right to be wrong.

The Social Club

This may sound familiar: you move to a new city and make a friend. Friend invites you to a party, a dinner, a rollerskating ball, whatever. You arrive keen and gregarious, but it quickly becomes clear that everyone already knows each other, have shared histories, and you're basically left to smile and nod. For many newcomers, this is how the Perl community feels, and much of the material written about Perl, in published books and online documents, only enhances this feeling of being an outsider.

Perl grew out of a Unix-based culture and, indeed, Perl itself revolves around a core collection of tools closely related to Unix ancestors, such as grep, sed, and awk. Consequently, many early adopters of Perl did share a common history with Unix and Unix-based tools. While Perl has, over the years, been embraced by programmers from all walks of life — including many with zero Unix history — the core and vocal Perl groups still refer to their shared Unix history in a way that probably alienates others. So-called "official" Perl books, such as the revered "Camel" (Programming Perl, written by Perl inventor Larry Wall along with other Perl luminaries) often introduce elements of the Perl language by first relating them to their Unix ancestors. Again, not an approach that resonates with those coming from non- Unix backgrounds.

Similarly, Perl insiders often make reference to the C programming language, another form of shared history that conveys little to those with different experiences. It might be rightly argued that these are not "flaws" with Perl, per se, but these factors tend to contribute an air of exclusivity to the Perl culture that distantly resembles the types of social clubs that circulated in high school.

Because Perl enjoys this social club air, comprehension of the subject is sometimes informed by a certain sense of smugness. Informal support areas, such as Usenet newsgroups and Web-based discussion, are ripe with condescension from those with Perl mastery who make grand gestures of their public displays of charity in providing obtuse, acronym-filled answers and "read the FAQ!" rebuttals to elementary questions. Unfortunately, these airs penetrate even formal support domains such as published books, by developers of Perl themselves.

The infamous O'Reilly & Associates Perl books, considered nearly official tomes on the subject, delight in their sense of humor. Much of this humor is tangentially related to how cool Perl is. More problematically, the humor itself invades the teaching, and we wind up with examples such as that found in Chapter 15 of Programming Perl, 3rd Edition, demonstrating the use of a named Unicode character in a regular expression. Here, the author jokes "If the Unicode Consortium ever gets around to approving the Tengwar script, then ...", and supplies a snippet of code naming a character from Tengwar: "\N{TENGWAR LETTER SILME NUQUERNA}". Of course, Tengwar is a language made up by Tolkien in his fantasy novels, and the joke is presumably more important than providing a real example from a real Unicode character that the reader could actually make use of and experiment with.

A Team of Individuals

Your office is a clutter, piles and stacks of papers, books, paper plates, moldy things ... you know the picture. To any outsider, it appears that the Tasmanian devil must have swept through the room a moment before. This one room alone probably confirms chaos theory. A visitor comes looking for a document, and you shoo them away: "I have a system!". You know where everything is, even if a spy satellite couldn't pick up one detail among this heap.

Perl is a great language for these people. Your code can easily reflect your office. Want to indent anywhere you like? Add whitespace anywhere that feels good? Perl isn't going to stop you. Maybe you'd prefer a single line 500 characters long. Be its guest. It's not a secret that Perl is structurally flexible, and the conventional wisdom is that Perl gives you "enough rope to hang yourself". Funny. But that's not the gripe — go ahead, hang yourself if you want. That's freedom.

The problem is that Perl also gives you enough rope to hang others. Nearly any software development of medium size or larger will tend to involve more than one individual. Now imagine that you switched offices with your co-workers every other day, and their office was just as much of a Star Wars garbage pit as your own, except that its their chaos.

Contents:

Common Criticisms
Simplistic Subroutines
A Toolbox Heritage

Run-time Timing - Page 159
The Perl You Need to Know Part 22: Warts and All - Page 160
Common Criticisms - Page 161