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.