The Reluctant Perl Programmer

Before you can solve a problem in a repeatable way, you must first understand the problem.

If you want to recommend a programming language, tool, library, or technique to someone, you must understand what your friend wants to accomplish.

The first wave of Perl programmers adopted Perl because it occupied a powerful and large niche somewhere between the Unix command line and C. It was easier to write small programs (especially for text-munging) than C and it scaled better from one-liners than shell scripts with sed and awk piped together with Unix utilities.

The second wave of Perl programmers adopted Perl because the system administrators had already installed it everywhere that mattered (this was before Windows realized the Internet came on computers) and because deploying a program that understood CGI was as easy as copying and pasting some code and plopping it in a cgi-bin/ directory with the execute bit set. Text munging was still easy. You didn't have to wrangle a compiler on the server. You don't have Unix pipes to string together, at least not very easily.

Today's reluctant Perl programmer:

• Just wants to get something done
• Has some sort of data-munging task, whether extracting data from a biological database, text from an XML file, or prices from multiple spreadsheets
• Doesn't know that the documentation exists, or how to read it
• Probably doesn't know how the CPAN works, or how to configure a client
• May know about the strict pragma
• Doesn't want to read the error messages
• Just wants to get something done

I hesitate to characterize a third wave of Perl adoption, because there's no obvious single third driver. The difference between reluctant Perl programmers and enthusiastic Perl programmers is that the latter sub-group embraces Perl as a whole. We take advantage of the CPAN ecosystem. We adopt new features and techniques. We refine them, keeping what works and discarding the rest. We revel in the social and engineering achievement of creating an unparalleled distributed testing and verification system which gives us Perl reliability.

We also get things done.

Perhaps the scope of the problem has changed. While it's easy to see that providing access to a few vital POSIX functions in Perls 1 - 4 was sufficient to solve the problems that most of the target audience needed to address and that adding a CGI module was sufficient to simplify web programming in the early days of Perl 5, how far can you go to address the divergent needs of reluctant programmers who are biologists, statisticians, linguists, financial analysis, attorneys, marketers, automation specialists, and testers?

I don't know if a biologist needs Moose in her base installation, but I know I'd rather have that than BioPerl. We are both likely to benefit from the presence of DBI, where a statistician isn't.

Not every reluctant Perl programmer will go to a YAPC or register for a CPAN author account or even ever read a programming book. Yet some will, if we encourage them.

We're great at building tools, and we're great at handing out free copies of our toolboxes. Sometimes we're pretty good at including instructions with our toolboxes.

Now how do we hand the right tool to a reluctant programmer such that he can just get the job done, understand that the toolbox exists, and learn just enough to make his next foray into problem solving even easier? Yes, new programmers will make messes. Yes, that's okay—they're likely to be so small that we can help them clean them up, such that their second programs are a little bit better and a little bit more ambitious and help them become stronger programmers.

It's not a question of education or deployment or bundling or installation. It's not a single question, anyhow. Maybe that means our best option is a guided tour of individual success using Perl. We can't find every individual reluctant Perl programmer, but those we can, we can do much better helping solve problems in the small and the large.