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]
Top comments (20)
After I learned async/await in javascript, I realized what a game changing feature it was for nonblocking application development and immediately set about trying to bring it to mojolicious. I had a Coro based solution on cpan within a couple months (most of that trying to make the backend pluggable which turns out to have been unnecessary) and then that success pushed me and others to advocate for LeoNerd to make his native implementation (Future::AsyncAwait) reusable enough that Mojo could attach to it.
I never would have had that drive to provide a feature if I hadn't seen how powerful it was elsewhere! Show your love for your favorite language by using others and bringing the best bits back home.
Me, I am a proud member of the Python community and I program in a number of languages including, but not limited to Python, Perl, awk, TCL, C, BASIC, Verilog, VHDL, ...
After working on the Rosettacode.org site for over a decade, I note that many languages have different sweet-spots in many areas. People might pick a language as that which scratches their bigest itch the best, and is half decent in other areas.
I find Perl to solve problems but still very good. In my company, a very large part of the software is still Perl code. To rewrite all that now would not make sense. Maybe a completely new project I would not start with it. I think golang would be an adequate alternative to implement the software we have in Perl. These are mainly system processes, workflows, or transformations of different documents. So far Perl is doing very well in this area.
I find it a bit sad that Perl is often made so bad. Actually, if you make an effort (e.g. coding standards) Perl is a very nice and extremely flexible programming language.
And I've also used almost every known programming language in my career.
I just retired from a 40+ year programming career. As you might imagine I've had to learn and master a large number of programming languages (at last count, 16). The last third of my employment was programming primarily in Perl, so right now it is the language that by far I am the most fluent. It is a powerful and versatile language and I really enjoy programming in Perl. But if you were to ask me what is my favorite programming language, I'd say it is probably the one I'll learn next. This has almost always been the case.
So true. I have always said that you shouldn't use a single language to teach anything, even if it's that language. Programmers solve problems, using a variety of languages, and also the technical experience to use the best language in any part of the development: tooling, web, data access... So lots of 👍 to you.
I said as much in my response to Nigel Hamilton's Perl and Raku growing as a profession - borrowing hacks from barristers. I've also been hired in similar situations as Dave: I told them I didn't know their tools, and they said that wouldn't be a problem. In a couple months I'm as proficient (usually more) than the the rest of the team. That's not because I'm smart: I just read more of the manuals :)
I agree with the point of the article, that a programmer should have as many tools in their toolbox as possible, but I also don't see a problem with a discussion group being devoted to just people programming in perl.
Not every group has to be about enriching the toolbox, some of them can be about discussing and improving your use of a specific kind of screwdriver. People coming into that group to talk about how great hammers are should be shut down as it is off-topic. As soon as a group's admins stop enforcing on-topicness, that group is doomed.
Oh, you're absolutely right. Which I why I didn't say that there shouldn't be a group for programmers who use Perl. In fact I'm a part of many groups that fit that description (including one on Facebook).
My objection was to the name of the group. Language is powerful. And calling the group "Perl programmers" can possibly encourage some of the problems I talk about above. I'd prefer it if the group was called something like "Perl programming".
Ah, see I thought the talk of the group's title was a metaphor, and one I think works very well. But if it is an actual objection, then I have to disagree that tiny differences in suffixes are as powerful as you're suggesting. Perl Programmers vs Perl Programming is a distinction without any practical difference.
As someone who used to code mostly Perl, but now sadly doesn't I'd be interested in a group called "Perl Programming" but not "Perl Programmers" because that's not what I am anymore and it sounds like it would be of interest to those who mostly/completely code Perl
"An experienced programmer should quickly be productive in pretty much any programming language."
Oh if only that were the case. I have many years of experience with Perl and C, yet find little of that transfers to C#, which I have been struggling with for the past three months.
I completely agree, in fact anyone who has been programming enough time probably had no choice but to learn several languages. In my experience that only makes you stronger and more aware of other ways to solve problems.
I mean, ideally you can just name a bunch of alternative languages and pick one that the interviewer is somewhat familiar with.
A smart interviewer might even take the chance to ask you which one you'd consider the best choice and why (which is a nice question because it shows lots of things about how knowledgeable you are and your thought process)
I don't think the article says that at all.