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
and the lead developer at Big Blue
Marble.
