Whipupitude Versus Very Serious Perl

Perl grew up in the rich soil of linguistics, the Unix philosophy, and a cheerful syncretism of multiple programming languages (I count among its ancestors C, shell, Ada, awk, and even a little SNOBOL).

Perl is happy to let you make a mess, if you get your work done, because its theoretical axe to grind is "it's important to let consenting adults get their work done".

Perl as originally envisioned occupies the sweet spot between writing code in C (a real programming language for real programmers who are disciplined enough to cross their Ts and dot their Is, lest they corrupt real data) and shell (an emphemeral toolkit for constructing temporary edifices out of soap bubbles and shoestrings). It's more powerful and flexible than the shell (but it never puts the shell out of reach) and it's more forgiving and gentle than C (but it keeps C within arm's length).

In other words, Perl was always intended to be the last tool you reach for if you don't have a specialized tool that fits the job exactly. You might even say that, like other languages of the same lineage and timeframe (Tcl certainly, perhaps Rebol or Rexx, or Lisp if you had a Lisp machine or Smalltalk if you never had to interact with the outside world or Forth if you always built your own OS from first principles on each piece of new hardware), Perl was a toolkit for building tools.

After all, that's the Unix way.

Then came Perl 5.

Actually, first came Perl 4 and the World Wide Web and forms of user interaction far beyond "I want to automate a common task". If you look at the features added to Perl 5 in the Perl 5.000 release, you see that the intent was always there to make Perl 5 into a powerful programming language for doing far more. Perl 5 is a language for writing big programs.

(The evolution of Perl 5 into what some people call Enlightened Perl and some people call Modern Perl is the process of discovering how to use Perl 5 effectively for programs small to large and how to manage that process. That's why we care so much about libraries, encapsulation, testing, and abstraction.)

Yet Perl retained its iconoclasm. You can still write Perl 1 programs in Perl 5. You can still write one liners that would give awk's creators pause. You can still decide how much formality or ceremony you want to undertake or forego.

Unlike, for example, programs written in Python, not all Perl programs have to look the same. (Yes, that's most often a superficial criticism, but bear with me. The original intent of Python was to produce a language suitable for teaching people with little or no programming ability. That single design goal, for good or ill, still governs discussions of which features to add or promote in Python. Python's lambda is what it is because the syntactic concerns of 1991 are still more important than the practical concerns of 2012, and Python's functional programming support is what it is because the perceived accessibility to novices in 1991 is still more important than the practical concerns of 2012, at least if you agree with my definition of the word "practical".)

That ceremony is important. Consider also Java.

The second program I almost ever deployed as a professional programmer was a website update notification system in 1998. I'd written a small help desk tracking application for HP earlier that year. Another group in the customer service department wanted customers to be able to subscribe to their knowledge base articles such that the system would send out notification emails when significant updates appeared on the public web site. (RSS was years away.)

I wrote a prototype for the backend service in six or seven lines of Bourne shell on HP-UX 10. Perhaps it was HP-UX 9. It used a flatfile. It integrated with HP's existing network. It strung together a couple of shell commands in a loop. It took five minutes to write and five minutes to debug.

The Java prototype (we barely had access to Java 1.2, so good luck finding modern libraries for such exotic protocols as SMTP) was at least an order of magnitude larger just to initialize the mail service. I spent about a week on it. I never finished it. (I was switching departments already.)

I wish I'd learned my lesson then: you can be pragmatic, but some people want you to wave your hands and utter magic incantations and pretend like you've done something impressive even if solving the problem takes a few lines of shell script.

Maybe I'm far too pragmatic, or far too honest to pretend that some problems are intractable or at least difficult, when they aren't. That story came to my mind when I read Scott Walters's unscientific observations about why you can't hire good Perl programmers.

Sure, sometimes Perl isn't the right choice. Sure, some Perl programmers are far better suited for system administration and automation than they are writing large applications. Sure, a really good programmer should know several languages well enough to be effective in any of them (with practice and focus). Corner any of the world's best Perl programmers and he or she will happily tell you about flaws in the language and the ecosystem. The same goes for the top programmers of almost any language. (COBOL and Fortran perhaps excluded, because they're ecologically the Galapagos Islands.)

... but any company which wants to measure success in programming does itself and programming a disservice by making the presence of ceremony or the number of lines of code or the complexity of tooling essential markers of Really Serious Programming.

If you think that all Perl is is stringing together a few lines of gobbledygook thrown in a cgi-bin/ directory somewhere to vomit some CSV exported from Excel onto a web site, go ahead and offer $15/hour on Craiglist and require an NDA before you let your new hire check out anything from CVS (and woe to him if he wants to check it out from home!).

If, on the other hand, you really want to solve problems, hire good programmers. Hire good programmers you can trust, then trust them. Work with them to figure out what you want to do. Pay them well, in both money and respect. Then let us solve problems.

Some of those solutions will be small automations. Great! Never underestimate the efficiency gains of small solutions accruing over time.

Some of those solutions will be bigger programs. We can manage this. We do it all the time—sometimes by breaking big problems into small problems, and other times by using the amazing global ecosystem of Perl and the CPAN and the Unix universe and the rich vocabulary of actions and information the modern Internet enables.

Sometimes we'll use Perl, because we're so amazingly productive with it. Sometimes we'll use something else, because we're so relentlessly pragmatic.

Yet keep in mind what you're paying for. If you want throwaway code written on throwaway contracts, the good news is that you won't have to spend much to replace it in six months. If you want good code written by great programmers who know how to solve problems small and large, treat us well and we'll deliver.

We'll write great code and we'll document and test it relentlessly. We'll reuse well-designed and well-tested libraries—in many cases, we'll even take on the maintenance burden of them so you don't have to—and we'll solve problems from small to large to the best of our abilities.

Just don't expect us to write more code than we need, and don't expect us to wrap the whole thing in some sort of mystical wrapper of ceremony and indirection. Whipupitude means that, yes, Perl is exceptionally well suited for programming in the small, but the continued evolution of Perl 5 and the CPAN and the Perl Renaissance of modernity and enlightenment means that we apply the same pragmatism to programming in the large.

Underestimate us at your own risk.