Don't be a Perl programmer

Dave Cross - Mar 8 '21 - - Dev Community

A couple of weeks ago, I left the biggest Perl group on Facebook. There were several reasons behind this decision, but the final straw was when they ran a poll to find the five top ways that Perl was better than Python. The poll quickly gathered some rather silly options but the discussion below the post was worse. A couple of people suggested that group members could learn something from taking a closer look at Python and they were slapped down by the group administrator. At that point, I realised that the problem was exemplified by the group's name.

The group is called "Perl Programmers". And I believe that people describing themselves as "Perl programmers" (rather than just "programmers") is one of the reasons why Perl has experienced a fall in popularity over the last twenty or so years. There are a few reasons for this.

Firstly, you're making the technology more important than the problems you're trying to solve. The job of a programmer is to add value to the people they are working for. That might be by adding new systems or by improving the existing ones. A programmer will do that by considering a range of technologies and choosing the ones that are most appropriate for the task at hand. A Perl programmer will presumably find the best way to solve the problem using Perl - thereby dismissing the vast majority of the available possibilities.

Of course, most programmers who enjoy using Perl will gravitate towards codebases that are largely made up of Perl. And in those circumstances, it seems likely that using Perl will be a good choice in that situation. But it might not always be the case. A client I worked for about five years ago had two massive monolithic applications that were written in Perl. So new features were also written in Perl. But these applications were so large and complicated that they had become very difficult to maintain. We, therefore, started on a project to dismantle these monoliths and replace them with microservices. And, as microservices are loosely-coupled, we were also freed from using Perl across the board. It became possible to write these replacement microservices in any language. Of course, as the existing team had a lot of Perl knowledge, most of the first microservices were written in Perl. But as time moved on and new programmers joined the team, new microservices were written in a number of different languages.

Secondly, Perl has always been the magpie language. When it was first designed, it took the best parts of shell scripting, awk, sed and several other languages and joined them together to create something unique. Even now, the language continues to borrow ideas from other languages in order to keep itself up to date. But in order to do that, members of the Perl development team need to know what interesting new features are being added to other languages. And if the Perl development team are keeping up with advances in other languages, then why wouldn't you want to do that too?

Thirdly, it will make you more employable. I mentioned above that Perl isn't as popular as it was twenty years ago. If you limit yourself to working for companies that explicitly look for "Perl programmers" then you're probably going to find it hard to find a job that you want. But there are plenty of companies out there that are looking for experienced programmers and aren't really bothered which programming languages you're experienced in. An experienced programmer should quickly be productive in pretty much any programming language. And once you're working in a company, you can start to quietly advocate for using more Perl inside the company ("Yes, that dashboard I built last week is pretty useful. I threw it together in a couple of hours in Perl - CPAN made it really easy.")

Two anecdotes to back this up. Between 2003 and 2008 I did three stints working for a well-known British newspaper. Only the first of those stints involved a significant amount of Perl work. In fact, when the manager contacted me to see if I was interested in coming back for a second time, I pointed out that they had replaced most of their Perl code. "But I'm not really interested in your Perl knowledge", he replied, "I want you here for your programming experience". On the other hand, last week, I saw someone looking for work in a (different) Perl group on Facebook. He asked if anyone was looking for a "Perl guy" and wasn't exactly overwhelmed by the responses he got. I see this all the time. The number of companies specifically using Perl (in the UK, at least) has fallen dramatically since the year 2000. Don't limit your options by making the same mistake I tried to make when talking to that manager. Realise that your Perl knowledge is transferable to other languages.

And finally, I think that looking at other languages will just make you a better programmer. All languages have their own strengths and weaknesses and it's interesting to explore what they might be. You will find weaknesses in other languages that reinforce your attachment to Perl, but you will also find strengths that you wish could be ported to Perl (perhaps they can be ported to Perl; perhaps you'll be the person to do it).

The best programmers don't consider themselves Perl programmers (or Python programmer or Javascript programmers or ...). They are programmers who know a number of languages and who know how to choose the best tool from their toolbox for any given task.

I should point out that this is very much a "do as I say, not as I do" article. For the longest time, I was convinced that I was a Perl expert and that's how I should market myself. I've already mentioned the conversation I had with the development manager at the newspaper in about 2005. But I honestly think that it took me another five years or so to truly accept what he was telling me.

Don't be like me. Don't think of yourself as a Perl programmer. Be a programmer who just happens to have a lot of experience with Perl. But don't be afraid to use that experience with other languages.

Names are important. That's why I think calling a group "Perl Programmers" can encourage an unhelpful attitude. But I'm not suggesting at all that you shouldn't be a part of the Perl community - that's a much better name for a Facebook group.

What do you think? How do you describe yourself? Do you think you've learned anything from looking beyond Perl (or, indeed, any other language)?

[Image by Daniel Iversen. Used under a Creative Commons licence]

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Terabox Video Player