Embrace the Reluctant Perl Programmer

Aug 27, 2012 by chromatic

editor’s note: an earlier version of this article appeared at The Reluctant Perl Programmer. Per the suggestion of Ask Bjørn Hansen, this revision appears on Perl.com.

Who We Are

We all love Perl for different reasons.

Some of us are programmers at heart. We love writing code. We love solving problems. We love that the distance between a problem and its solution is often a few lines of Perl which flow almost effortlessly from our minds through our fingers to our screens.

Some of us are administrators. We love order. We love consistency. We love knowing that the scripts we wrote in 2008 or 1998 or 1988 run unmodified on every system we touch and we don’t have to think about it. We love that Perl doesn’t get in the way of our solving problems, whether we have a few minutes to fight a fire or a few weeks to plan something big.

Some of us are artists. We tinker. We play. We experiment. We write poems and steal features from wherever we can find them. We color outside the lines, and we love the flexibility we have to let our muses take us where they will, because we know that Perl will stay out of our way.

Some of us are engineers. We love reliability. We love working software. We love when an upgrade is boring, when there are no unpleasant surprises. We love having the CPAN always within reach, with far more great software than we can ever use there for us whenever we want it.

We are many and we are varied. We build great things, and we collectively make up something even greater.

We started with the vision of one man far too lazy and hubristic to solve a simple problem of cross-continent communication in the easy way. We grew as system administrators acknowledged that something more powerful and consistent than shell but simpler and more forgiving than C occupied an enormous ecological niche. Then we grew again as we realized that a web server could do more than just serve a plain static page, and that wrangling text was a job for a powerful, malleable language.

Along the way we built something grand.

We’re pragmatic. We’re relentlessly pragmatic. We get things done. We iterate and improve and refine. We’ve stolen the Unix ethos (build many small tools, loosely coupled) and turned it into the CPAN and the ecosystem around the CPAN such that, at times, the CPAN is our language far more than Perl is, and many of us are all the better for it.

Yet not everyone can benefit from that.

Who They Are

We stand on little ceremony, but we do stand on ceremony. Some say the “right” way to write Perl is a thin layer of glue connecting as much of the CPAN as you need. Others suggest that the “right” way to write Perl is the code they wrote in 1987 when Larry first introduced his work to the world. Most of us are somewhere in between.

Most of us are somewhat wrong.

Consider the plight of the reluctant programmer who faces a problem. He or she may pick up Perl, and what then?

Where does this reluctant programmer go for information? Where does this reluctant programmer go for help?

Where can you learn that the first dozen Perl tutorials easily found with a search engine are out of date or even wrong? Where can you learn that any of a dozen good text editors or IDEs are available and are better than notepad.exe? Where can you learn how to install CPAN modules on ActivePerl (or that Strawberry Perl exists)—and more importantly, why?

Where can you go from “I need to process this report by the end of the day, and I have this text file, and I heard PERL was good for that?” to “I can solve my problems with this language, and I never considered myself a programmer before!”

Those of us who’ve already undergone that transition may find it difficult to remember the days gone by. We’ve spent so long shaping the language, our tools, and our community to fit our problems, perhaps we’ve forgotten both the energy of promise and the growing pains of our youths.

Once upon a time, we all just wanted to get something done. There is much to admire in that approach. By all means, let us continue solving problems. Let us encourage people to solve their problems. Let us solve problems so well we never encounter them again.

Let us not forget, however, to let reluctant programmers solve their problems immediately, however poorly, and only then help them open their eyes to the new possibilities their successes now afford them.

Who We May Be

This change is a change of mindset, not of technology nor tools.

With few exceptions, our growth will not come from those who already know the beauty of programming and the freedom of Perl. It will come from those who merely (as if it were a mere thing!) wish to solve a problem. If and when they succeed, they will need guidance to understand the new powers they possess, and we can be there.

Yet first, we must accept that their goals are not our goals—not yet anyhow, and perhaps not never. Their goals may be strange to us, but they are no less valuable for their peculiarities. In truth, that makes them more valuable. These are more problems for us to solve, more ideas for us to adopt, and more people to welcome into our community.

By all means, let us help them write great code and let us teach them the value of working with the community in the structures and per the techniques we have developed to harness our powers. Let us mentor them so that we may welcome them as peers and equals in ability (even as we acknowledge them as worthy of respect and praise from the start). Yet let us first welcome them into the greater Perl community with all of the pragmatism we embrace.

All are Welcome

Reluctant programmers, come solve your problems with us. We are proud of what we have built together, but we build beautiful things and share them with you because in their use we find the greatest beauty.

You are welcome here.

chromatic is the author of Modern Perl: the book.