Channels ▼

Open Source

Why I Use Perl...and Will Continue to Do So

It was alarming to read in the recent article The Rise and Fall of Languages in 2012 by Dr. Dobb's editor, Andrew Binstock, that Perl was "continuing its long decline" and was in"an irretrievable tailspin," based on statistics from Google searches. Nothing in the article discussed what was lacking feature-wise in the language that might be behind this decline. While I am not an authority on programming languages, I thought it was only appropriate to reflect on the strengths of Perl that I've relied on during my 14-year affair with the language.

My History with Perl

I stumbled upon Perl back in 1999. I was an FPGA Logic Designer at Lucent Technologies proficient and programming in C, C++, and VHDL. Web Programming seemed like an exciting world and Perl was advertised as the "duct tape" that glued the World Wide Web together. After a one-day workshop at Lucent, I quickly realized that Perl was a godsend to hardware developers. It combined the power of C and AWK making it a great language for developing hardware automation tools. As a logic designer, Perl augmented my abilities by providing me with a powerful language that was easier to create tools with. I created tools for "stitching modules" for chip design and testing, and designing two-pass assembly languages customized for test benching VHDL/Verilog chip design.

Nine years ago, I move into testing, automation, and tools. Since then, Perl has become a fundamental tool in most of my development work. And I got really good at using the language. Whether writing tools to help hardware developers audit their schematics, writing factory tests, doing data extraction and conversion, or database interfacing, Perl has made my life easier. And Perl/Tk was there to create GUI interfaces for many of my tools. Of course, Perl cannot do everything, and I use it in conjunction with other languages as well: Labview, Javascript/jQuery, and SQL to build end-to-end data systems.

The Power of Perl: 10 Good Reasons

Over the years, my fondness of Perl has only grown stronger. I write anywhere between 5,000 to 15,000 lines of NCL Perl code a year, from throwaway scripts to large-scale and robust factory test applications. The following list of the reasons I particularly choose Perl for my work might help other developers determine whether Perl is the right choice for their needs.

Regular Expressions

Regular expressions are the most compelling attraction of Perl. It is no secret that Perl regular expressions are the envy of other languages. As data continues to have an ever-growing importance in today's world, regular expressions provide us with the power to slice and dice data so that we can measure, learn, and make intelligent decisions. Good regular expressions, such as those in Perl, will therefore become increasingly important.


Hashes or content-associative arrays provide us with a quick way of creating lookup tables. And in the world of data and automation, lookup tables are indispensable for creating tools. Listing all the great ways of using hashes is beyond the scope of this article. The vast majority of my applications would not be possible without the power of Perl hashes.

Memory Management

A programmer's productivity is greatly enhanced by not having to manage memory allocation and deallocation. Arrays and lookup tables can grow and shrink as need dictates. Complex structures can add and remove fields on the fly.

References and Complex Structures

Serious programming requires the ability to create complex structures. Perl supports references/pointers, which is key to being able to create complex structures. Again, there is no need to pre-declare fields. Keys can be added and removed on the fly.

Modular Programming

Large-scale programming is not possible without support for modules. While Perl can be used for pure scripting, it does enable modular programming using packages. Many of my applications consist of 20 or more modules, with each module housing a single subroutine call. Packages are also used for doing OO programming in Perl.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.



Had you ever used grep, egrep or the C library for regular expressions?

Perl did extend the standard in some helpful areas, but I've found most Perl programmers who love RE didn't know that RE were independently developed and were added to Perl.

To me, Perl is a gumbo of shell, awk, sed, grep, a bit of C. Like most gumbos Perl is murky and contains unpleasant surprises.


No matter what people start or stop saying, they're not using Perl for new projects.

There's still a mountain of write-only legacy Perl in production and will be for a long time.


Perl's problems run deeper then the idiosyncratic syntax. Default global variable scoping is exactly backwards ( all those "my"s, ) no namespaces for imported modules; ( where is that function defined? search all the imports, ) "majik variables" like $_ for loops and such, no-name function parameters ( alternately; no function signatures. ) These flaws are part of the reason our team is rewriting our legacy Perl in Python; so we can actually work with it.


And Python's powerful functional aspects have no parallel in Perl.


Not to argue too harshly, but there's nothing terse about sigils.


It's not just the OO, Pythons data structures are a lot easier to use and it has more of them built in to the language.


I needed to choose between either perl or python for a medium size scripting project a few years ago, had not used either one previously, so spent a few weeks on each trying to decide. Turned out perl was much more cryptic with its syntax, python to me was the much easier one to use, so in reading the merits of both, I chose python since the end result would be the same with either language, but could get the job done quicker with python. Being a novice with both languages it just seems python is much less cryptic.


As someone who performs serious data munging and transformation on a regular basis I find Perl the perfect tool for the job. Sure, Perl's OO doesn't compare to Python but for not every job requires serious OO (or any OO for that matter). Languages will emerge which are superior in some regards to Perl and that is as it should be. There is a core set of use cases for Perl, however, which will likely never be replaced.


I'm just adding a data point here - numerous comments have made most of the points about Perl that I am about to reiterate. I work with other people and use whatever language is prescribed for a particular project. I used Perl as my main language (not just for scripting, but for production code as well) for about three years. My observations are:

Yes, perl is extremely powerful, elegant, and terse. There isn't much you can't do well with it. If you are using x-nixes, there is a good synergy with the command line and shell scripts that is helpful in remembering, for example, all those $ combinations.

When my perl product went out into the world, I went back to other projects mainly using C++, then C# (and also mostly on Windows rather then x-nixes). My use of perl for quickie data-massaging programs and scripts declined after I stopped using it every day, because I find it to be a language skill that needs to be exercised regularly, more so than most other languages.

I now most often use Python for the same kinds of purposes I formerly used Perl for. Why? I find it easy to read, so that I can pick up a project I've put aside for a while. For writing code I find the syntax comes back to me more easily than perl does. Because of the readability, I can show programs to colleagues and even if they don't know Python, they usually have a pretty easy time understanding what the program does. (perl-ites reading this are no doubt thinking, Python = perl for dummies. Maybe so, but it works for me). I also find object-oriented program organization pretty easy to do in Python, and object-oriented program organization is a habit with me.

Of the dynamic languages I've used, I find the power of perl, Ruby, and Python pretty similar. Powershell is powerful for scripting and little programs, too, but being Windows-only and, like perl, forgettable for me if I don't use it for a while, I haven't really warmed up to it. For me, Python is the least strain for an irregular user.

So, if you use perl regularly (or maybe just have a more supple memory than me) and like it, more power to you. No reason to stop. I don't see any reason to think perl is in danger of extinction in the foreseeable future. But if you're an irregular user of dynamic languages, you might consider the other ways there are to get similar levels of power and adopt whatever suits you -- your mileage may vary.


We are still running COBOL and FORTRAN code... But ask yourself:
- would you recommend someone trying to learn programming to start with Perl? Would it be in the TOP 3 category?
- would you recommend someone starting a new project to write it in Perl? Would it be in the TOP 3 category?

If there's no new blood, the decline has already started. With little new programmers and few new projects, the path to irrelevance is straight ahead.


Great article. The death of Perl is pre-mature at best.


I liked your response. Just wanted to add that Eclipse supports Perl via EPIC at
Just FYI -- you may have already known this.


Loved your story about Perl Andrew. Back in the 1990's, when I was trying to figure out how to search and "wrap" marketplace pages (eg: eBay) ... basically making my own APIs (before APIs existed), I bought the book Mastering Regular Expressions ( Then, I sat down and hammered out (after an enormous amount of trial and error) a really cool application that looked across marketplaces for specific products on the aftermarket. It worked so well and in the years following, as I heard about other languages like Python that might have more to offer, I inexplicably defended Perl because it was with Perl that I achieved such dramatic results (in such a short period of time) and thus formed my first love. Sometimes, we let our emotions get the best of us when defending something that, in the face of overwhelming evidence, is really indefensible.

Some time has passed now. If I ever went back to coding some sort of regex processor, I might be willing to consider something else. ;p


I have just been in a project to upgrade a site having a mixture 10 year old Java and Perl and Microsoft ASP applications to supported infrastructure, (Replace old Oracle Application server with JBOSS etc. ) The Perl code ported over with little or not work. The Java Code cost thousands of hours or labor. The ASP based applications required a total rewrite. This project changed my views on Perl.


I use Perl, but restrain its use heavily as it has a diminishing sweet spot when I regularly choose between sed/bash/Awk/Perl/Python that I can program in. Perl is left with that one-liner - often with the -p -i -e switches where its code structure (usually regex based) is better than Awks and you can squeeze it on one or a few lines. Any more and I switch to Python as Python's data structures are more powerful than Perl's (you can leave behind reference unmangling in Python) and Python is vastly easier to read and reason about.


As a former Perl user (up to and including paying for an ASPN subscription for several years) I'd say that the points you are making can equally well be made for Python and for C# - both of which I vastly prefer if Perl is the other option.

Yes, you can do most everything in Perl. But understanding Perl code when you have been away from it for more than six months is usually a pain that I prefer not to endure.


The one non-feature of Perl is that you forget it (or, rather, many non-obvious syntax choices and quirks in the language) as soon as you stop using it. So, I think, that's one reason for Perl's decline, because once a developer got off the language, it's hard to get back on. And that given developer is in fact motivated to switch the language, it's just as hard as learning Perl again from the start, and grants you one more skill.

Hardcore Perl developers are actually blindsided to this problem, because they love the language and never leave its loving embrace long enough to forget :)


For me, there is simply no language that I find quite so bewildering as Perl. I really don't think that is a characteristic of the language so much as a set of traits and limitations of my own.

The main question I face with Perl is not how you might do something, but rather why you would do it in the way that seems indicated. Yes, I always think, I could do that. But really, I just can't quite see myself doing it that way.

I've always thought this is largely due to my preference for O-O languages. Yet I see from Ward Cunningham's interview that he really likes Perl and uses it regularly. And Ward, of course, is a very adept O-O programmer and thinker. I sighed when I read that. It's another reminder of just how limited I really seem to be as a programmer.

What is most interesting, however, is that there is something about Perl that seems to touch on something particular in programmers. For example, my two favourite languages are Smalltalk and Lisp. (I'm learning Scala right now, and I rather like Dart as well.) They usually do not even make it onto lists of languages falling into disuse. Yet I really don't mind.

However Perl users do seem to be upset by suggestions their language no longer quite belongs to the "cool kids".

My impression is that for many Perl programmers their discovery and use of Perl was very central to their development as programmers, and to denigrate the language can appear to them to (in an associative, emotive, psychological sense) denigrate that development as well.

Whether my sense of Perl programmers is true or not, I don't really think anyone disrespects Perl. Much of its diminishment in popularity (which does seem accurate and actual in my experience) has not to do with the language's failings, but the multiplicity of choice out there.


I have used Perl professionally and personally since the mid-1990s. It is my goto language of choice for any project not low-level enough to do it in C.

Perl may or may not be declining, but the Perl community seems to be as strong as ever.

In any case, one project I did demonstrated both the high performance Perl was actually capable of along with the elegance of high level abstraction. I wrote a multi-processing email sending engine (think Lyris but without any bells and whistles). On a humble dual CPU P4, I got it up to 70 processes communicating back and forth with a master dispatcher, sending 170k emails per hour in aggregate, and there were still a few decent optimizations I had in mind before I moved on. All in a few hundred lines of code using custom epoll (no select() for this baby!) and SMTP (using the plain sockets API) modules.

As far as the syntax, I love its expressive conciseness, and I have barely even gotten to the newer 5.10 (and later) features.

I work in PHP when I need to. And I am doing a lot more Javascript coding, and that's also a language with warts that can really be appreciated with its relative flexibility, to have been able to get to the point today where serious work gets done in it. But for anything that doesn't involve a UI (like web serving or server cron jobs), Perl is my first and only love (:-).


I like Perl, I use Perl, and I will probably always use Perl when I can. As Sammy points out - it is very good at doing a very large number of things. And while not all people love all aspects of the language, IMHO it does what it does better, and more normally, then many other options - say like PHP. Which I also use a great deal. Regardless, I do like Perl.


I have used Perl since the mid 90's (Perl 4). I agree with Sammy in that it is a very powerful language. I still use it today in many of my projects, anywhere from simple scripts, automating network audits, generating reports, even full GUI applications (using Perl/Wx). While some of the syntax can be hard to understand at first glance, once you do, you will appreciate the power and flexibility it gives you.

TMTOWTDI (There's more than one way to do it).


I used Perl for well over 10 years, and still (as you suggest) admire the elegance of its regular expression implementation.

Two issues led to my switch to Python starting in 2004. First was my need for good object-oriented programming support, which IMHO is ugly in Perl and beautiful in Python. The second was my need for an embedded script language in large tools I was developing in Java and .NET, for which Python has Jython and IronPython, but for which Perl has nothing.

Python has since become my favorite language for small to medium size projects, and I'm happy to find it has increasingly become well-supported as a script language for tools in my environment - Gnome, LibreOffice, Gimp, Gedit, Eclipse, etc. I've even, to my surprise, come to love indentation-based scope. ;-)

But if you love Perl, by all means continue to use it and to tell others why. Choice is a *feature*, and Perl is a nuclear-powered Swiss-Army chainsaw of a language (and having cleared quite a few forests with it myself, I mean that as a sincere compliment!).


Thanks for sticking up for Perl. I question the original article, or more particularly the "research" it's based on. The fact is there's no reliable, scientific measure of program language usage. Is Perl declining? I won't be convinced by someone looking at TIOBE or "google searches". Everyone knows TIOBE is meaningless. Dr. Dobb's shouldn't be citing such sources. This is a job for the likes of Slashdot.

As one data point, I was pleased to notice a guy on the bus today (an Akamai programmer, I believe) reading the new edition of the Camel book. So apparently the strange rumour I heard that they were replacing their Perl with Clojure was false or the project never came fully to fruition (or maybe they just have a lot more Perl than this one project they were looking at Clojure for?).

Hey, maybe I should start tracking which programming books I see people reading on the red line through Cambridge, MA. If someone wants to write the same silly article next year about what's in decline, I'll even let you use my research for free. You can add it to the other nonsense studies, see how they compare.


Perl is not on the decline. So stop saying it. Stop listening to people who quote the useless TIOBE index.


I used Perl for a few weeks in the late 90's. While I do not dispute it can efficiently do the many things and more you mention in the article, you did not emphasize the syntax.

I found that many things in Perl required an idiom (such as appending to a string) which once learned was usually a terse way to accomplish the task. However, in my experience, the idioms required were many and I did not reach the stage in which I was able to guess what an idiom for a task might be. My experience with most languages (I have used over 50) is that after some time an experienced programmer is able to predict correctly the syntax for a never before used task.

As good as Perl is, I would suggest the syntax is one reason for its decline.