This autumn marks the twenty-year anniversary of my entry into professional programming, joining friends at the (dearly departed) Maine Internetworks. I’d learned Pascal in my undergraduate computer science classes a few years before that, and transferred what I could remember from that into learning Perl for this new job (along with some PHP, JavaScript, and C along the edges). I still use Perl almost every day, and I am in such a weird place with it right now.

I continue using Perl as my go-to general-purpose programming language despite the repeated declarations of its demise that started around the post-dotcom doldrums of the mid-2000s. I’ve worked in technology enough to learn to ignore pronouncements like these, as well as any shiny new creative tech that comes along — so long as the one I’ve gotten really good at using still works, and still has a community of comfortable size and temperament supporting it.

Perl, for all its relatively shrinking stature, has not fallen beneath this threshold, and I don’t actively fear that it will any time soon. It has enjoyed a new release every year for the last decade. Its humbly sized annual conference feels like home. I know that I can ask a question on IRC (either on Perl’s own network or a handful of project-specific Freenode channels) and I’ll get smart and thoughtful responses every time. I have yet to feel anything close to approaching a dead end with Perl; BumpySkies, only two years old, would not have happened but for open-source Perl modules dealing with highly specific matters of geographical math and obscure scientific file formats that others had recently shared. And those rare times I actually manage to find a topic so new that I blaze my own trail into CPAN, I very much build on foundations laid by many others.

And yet. While I can’t agree that Perl is “dead”, I do admit that it feels suspended in a strange limbo, lately. Part of this comes from my exposure, starting last summer, to technical conferences based around some concept other than a programming language. This began with !!Con 2017, which I enjoyed so much that I petitioned The Perl Conference to steal its ideas. I went on to attend All Things Open later that year, and then this year I went to the tiny IndieWeb Summit, with an attached visit to a Donut.js meetup.

At at !!Con and Donut.js in particular, I found myself significantly older, whiter, and maler than the average attendee. These are both smaller, high-energy gatherings based on people sharing personal stories of technological triumphs, obsessions, and transformations, and it seems natural they’d attract a more diverse crowd than a more staid or narrow-topic conference would. But when I later attend a Perl Conference and I see that the vast majority of attendees are, morphologically and culturally, of a type, I start to feel the creeping sensation that my favorite programming technology is missing out on something. Like it continues to burn fuel it purchased in 1998, paying no mind to alternative energy sources that may have appeared since.

As far as I can tell, good reasons to learn Perl in 2018 include these:

• You are joining a company or other software-project team whose work involves Perl.

• You come across an open-source project that you want to contribute to, and it makes use of Perl.

• You want to learn programming in general, and you are the spouse/child/sibling/mentee of, or otherwise one with extensive personal access to, a Perl expert with the time and inclination to help you learn Perl in particular.

But, crucially, this is probably not a good reason to learn Perl:

• You want to learn programming in general, and have no reason to choose one language over another, so long as it’s easy to start playing around with using your current computer.

Even though Perl technically qualifies under those latter criteria — many operating systems come with some version Perl pre-installed, for one thing — I would not recommend it to a novice programmer who doesn’t qualify for any role in the first list. Without a doubt, the “winner” there is Python, and this comes entirely down to its much greater diversity of culture and ecosystem. I have not attended any Python-specific conferences or other events, but I can tell from a distance that they much more resemble !!Con in having a broader spectrum of personal energy than any Perl conference.

Unless I planned to actively help shepherd the person through the best parts of Perl’s sparser ecosystem — and, consequently, warn them away from its trouble spots — then I could not in good conscience welcome a code-newbie to it. Not when I could instead send them off to a community where they would have a far greater likelihood of finding people more like them making things more interesting to them.

It feels, then, all the more like a paradox that I myself don’t take my own advice and follow this notional newbie into Python’s arms. I have no doubt that I could thrive in that ecosystem at least as well as Perl’s, if I had to. It would bring with it all the joys of working within such a larger, brighter, and more many-voiced environment. Sounds pretty good.

But the cost! It would take me calendar-years of intense study — stealing time where I can, in between all my current commitments — to attain a level of Python expertise similar to that I’ve earned in Perl over decades. And once there, I could… do pretty much everything I can do in Perl today, except without the nagging doubt? It just doesn’t seem worth it. More to the point, I just don’t realistically see myself ever making the necessary investment of time and attention, not when I could instead make things using the Perl tools and techniques I’m already expert in. (To say nothing of doing things that don’t involve programming, now and again.)

I can’t give marching orders to the whole Perl community in order to make its situation feel a little less script-lost. I can only describe what I plan to do: attend more language-neutral gatherings (I’m going to another this week!), and contribute my expertise to poly-technology projects and organizations (I help run one!). I will also continue to release open-source software that happens to use Perl — and, as much as time allows, do my best to set a stellar example of how lovely a modern-dialect Perl-based project can look when it uses contemporary, team-based development techniques like code reviews and continuous integration.

I want to see scrappy little Perl stay a viable option for the rest of my career as a software toolmaker, even if I concede that it has long since “lost” to Python as the single dominant technology in its realm. These sorts of personal-level projects and contributions represent my attempts to increase the field of broadly interesting and visible stuff built with Perl, so that hackers who’ve earned their programming chops via some other gem or snake might discover them, and maybe want to get in on it as well.

I have had the good fortune to personally witness this phenomenon with projects that I lead. While I’m no deep expert in any, I have learned a little Python (or Node, or Objective-C…) in order to create or contribute to something I cared about in an environment which had already chosen its language. And coming the other way, I have absolutely seen with my own eyes — and helped with my own time — folks pick up a little Perl in order to patch projects near and dear to me. It really does work!

I stand by my bullet-list of reasons to learn Perl, in part because I see it not as evidence of a hopeless dead-end but an opportunity to grow Perl’s ecosystem by widening the space implied by that second item. I plan to do what I can, and I invite other Perl hackers who share my concerns to join me: write and share open-source software that attracts contributors for some reason besides being written in Perl. Let it become a quietly shining vector to help create more Perl programmers, bringing more voices and backgrounds into a creative ecosystem that very much needs them.