Whipuptitude and the Marketing Gap


In Lack of Ceremony and the Marketing Gap, I argued that Perl's unwillingness to force any particular development style or structure has contributed to the misperception that it's difficult to write consistent, coherent, and maintainable code (as if microblogging makes sestinas impossible).

I also mentioned whipuptitude as a factor in Perl's power and perception. Adam Turoff gave the best definition:

Whipuptitude is the property where, starting from zero with a large library of easily combined tools, you quickly hack a solution to a moderately simple, but annoyingly tedious problem that occurs frequently.

— Adam Turoff, Manipulexity and Whipuptitude

Whipuptitude is a deliberate design decision. Some people call Perl a distillation of the Unix principle; read Usenet from the early '90s for long discussions of this concept and implications. In short, the design goal is to give people the ability to combine small tools in ways unforeseen by the language designers to solve their problems.

Sometimes that means shelling out to grep and find. Sometimes that means writing Perl one-liners to stick in a long piped shell command. Sometimes that means writing a language agnostic testing protocol and communicating with software written in a dozen languages to produce a single good report.

Some people call this scripting. Other people call it glue.

Combine this whipuptitude with the lack of ceremony, and you have the ability to create nice abstractions as well as the ability to throw some spare parts together and hope it holds long enough for you to get your job done.

When you see ugly glue code written in Perl, you see scrappy programming, chicken wire and paper mâché, thrown together in a hurry by someone who didn't take the time and the effort to put things together the "right" way -- as if there were a single right way. Perl doesn't hold your hand and force you into a theoretical axis. Perl doesn't take away features it thinks you're not ready to use. Perl's like English; you can speak a pidgin if you like, if you think that'll communicate what you need to communicate effectively. Yet woe to you if you write the instructions for baking a cake in a pidgin that leaves out important information and you end up with a soggy brick that not even your cat will eat.

It's all up to you how maintainable and portable and efficient and effective your code needs to be. (Most programmers are lazy.)

There's a flip side to this whipuptitude, and that's how it scales to larger projects. Perl's not only good for throwaway ten-line programs that massage data from one text file to another (though it's shockingly good at that; yesterday I debugged a garbage collection tuning problem in Parrot by annotating the GC with simplistic fprintf() statements and massaging the output). Properly applied whipuptitude works at the macro level as well.

You see this at its best when you look at the CPAN. Consider it not as a collection of additional libraries, but as a set of easily-combined tools intended for quick assembly to help you solve modest but annoying problems. Moose? A better object system than the default. Try::Tiny? Effective and complete encapsulation of everything you need to know to handle exceptions safely. WWW::Mechanize? Simple automation of web requests. Modern::Perl? Scrapping the boilerplate to enable Perl 5's nice new features. autodie? Remove tedious return code checking without reducing the safety of your code.

Perl programers extract tools and make them reusable. Whipuptitude isn't just for small programs. It's how to make great medium and large Perl programs as well.

(There's a dark side to this, however. ExtUtils::MakeMaker is a glue wrapper around the make utility which attempts to enable portable shell programming around operating systems, shells, and make variants. Sometimes even core Perl gets things wrong.)

Next time: DWIMmery.


In MakeMaker's defense, it made sense at the time when Perl was just a Unix program, every Perl user had make and Windows was still a DOS program.

Cats are notoriously picky. I bet they wouldn't eat a cake if it was made from Moose.


Sure, but it's easy to argue that it stopped making sense around the release of Perl 5.6.0 in March 2000. (It's more difficult, but still possible, to argue that supporting several make variants after having Perl itself available was a mistake even before that point.)

A snippet from IRC yesterday on this topic:

<Nacmac> I do feel this is an interesting statement and wonder if anyone here has a reaction to it: "What this means is that Perl demands far more time out of a developer to become proficient at it, while offering no significant benefits for someone investing this extra time."

<Khisanth> Nacmac: my response would be bullshit.

<hobbs> Nacmac: I'd say that's essentially the opposite of the truth -- just think of the number of admins in the world who write Perl without *ever* really knowing it

<Nacmac> Hey now, hobbs, I resemble that remark.

<hobbs> Nacmac: they're certainly not writing elegant programs, but they're getting shit done with minimal investment.

Modern Perl: The Book

cover image for Modern Perl: the book

The best Perl Programmers read Modern Perl: The Book.

sponsored by the How to Make a Smoothie guide



About this Entry

This page contains a single entry by chromatic published on December 2, 2009 2:03 PM.

Lack of Ceremony and the Marketing Gap was the previous entry in this blog.

DWIM and the Marketing Gap is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.

Powered by the Perl programming language

what is programming?