Why Perl is still relevant in 2022
If you love UNIX/Linux/BSD like me, then you have definitely learnt Perl and programmed in it. I am pretty certain you have also used Perl more than once, perhaps several times. The language was created in 1987 as a general purpose UNIX scripting language, but has undergone many changes since then (even spawning another programming language, Raku).
You may have used it for occasional sys admin tasks, in your tool chain, or to enhance some shell scripts that needed more gas. But Perl is more than just scripting.
But from the amount of talk about Perl on Reddit or Stack Overflow, you might think it’s dead. It’s far from dead, and is still very relevant to software engineering today.
From https://insights.stackoverflow.com/trends?tags=perl%2Cbash%2Cnode.js
What makes it special?
Perl is a high-level, interpreted language. It is open source and free to contribute to.
Perl’s primary strength is in text processing. Be it a regex-based approach or otherwise, Perl is excellent for logfile analysis, text manipulation, in-place editing of files, and scouring structured text files for specific field values.
Perl is very Unix-friendly. It can serve as a wrapper around Unix tools and is fully integrated into OS semantics. As a result, it excels at pipes, file slurping, inter-process communication, and other geeky tasks. It can create Unix daemons or server processes that run in the background. We can easily invoke a Perl daemon to avoid spending hours working on C and reduce security flaws.
Like npm for Node.js, Perl has a vibrant development community in CPAN, with a vast archive of Perl modules. You can find a module to do anything you want. Most modules are written in pure Perl, though some performance intensive modules have an XS component that uses C for performance.
Through CPAN, you can wrap many databases—SQLite, MySQL, Postgres, and more—in Perl code using database driver (DBD) modules. These export the DB operations using Perl’s own semantics into unified portable Perl code that hides the complexities of the database.
Perl supports arrays, hashes, and references using which you can code in very powerful ways without thinking deeply about data structures or algorithms. Most CPAN modules give you both a procedural style as well as the object oriented one. By giving you that choice, you can pretty much do your task your own way.
What sort of problems make Perl a natural?
As stated above, Perl does very well with text processing. It can scour CSV files for data fields based on complex regex statements. It is a tool of choice for parsing log files. It can quickly edit settings files. Perl is also a natural for various format conversions, generating PDFs, HTML, or XML.
Since the early days of the internet, Perl served as the foundation of a lot of basic networking tasks: common gateway interface (CGI), MIME decoding in emails, or managing websockets between a client and server. It has evolved a lot since these early times, becoming a source of inspiration for other ecosystems and getting inspiration from other languages to evolve.
For power Unix users, Perl allows you to automate nearly any action that you like. You can create daemons—small, constantly running programs—that will automatically take actions when their conditions are met.
Testing is at the core of Perl culture. Excellent test toolkits and infrastructures lay at the foundation of the community favorites methodologies. Any module uploaded to the CPAN will pass automatically through the *CPAN Testers Reports, a multi-platform testing ground that has operated since 1998. Standard Perl tests can also be run in common build pipelines and CI/CD.
A flexible and fun way to code
In today’s event-loop-centric asynchronous world of JavaScript, Node.js, and TypeScript, Perl developed ways to face the challenges of non-blocking programming.
Despite asynchronicity not being a fundamental part of Perl’s core, it is as always possible to extend the language through CPAN modules. A robust example is Future::AsyncAwait
that provides syntax for deferring and resuming subroutines with the async and await keywords. An alternative is Mojo::Promise
, a Perl-ish implementation of Promises/A+ and a superset of ES6 Promises.
Perl includes a number of specialized operators that process data in unique ways. You can use the diamond <>
operator to eat up any stream, file, socket, pipe, named pipe, whatever.
The regex operator =~
opens the door to the rich world of Perl regular expressions, that can reduce many lines of complex code to a couple of match
and replace
operations.
Perl emphasizes the get what you want the way you want philosophy, also known as TMTOWTDI.
Perl is multi-paradigm. In addition to procedural or object-oriented, it allows functional programming. Depending of the situation, it allows to choose the most accurate programming paradigm. Providing a low level object-oriented system, robust object toolkits like Moose can be used for production code (from CPAN, not a core module). Such toolkits greatly simplify the object-oriented paradigm for Perl.
Looking at some code
Let us examine some code samples to get some perspective by creating a sha256 digest of a string.
This is how you do in Node.js:
const {
createHash
} = require('node:crypto');
const hash = createHash('sha256');
data = 'Stack Overflow is cool';
hash.update(data);
console.log(hash.copy().digest('hex'));
Let’s examine two ways (more ways could be possible) to do this in Perl. One is the procedural approach:
use Digest::SHA qw(sha256_hex);
my $data = 'Stack Overflow is cool';
my $hexdigest = sha256_hex($data);
print("Procedural interface :: " . $hexdigest . "\n");
Another is the object-oriented approach:
use Digest::SHA
my $sha = Digest::SHA->new('sha256');
$sha->add($data); # feed data into stream
my $hexdigest = $sha->hexdigest;
print("OO interface ::" . $hexdigest);
Here’s how you do it in Python:
import hashlib
m = hashlib.sha256()
m.update(b"Stack Overflow is cool")
print(m.hexdigest())
Debugging
Perl has a -c
switch to just compile the code to check for basic syntax errors.
You can always use the die()
diagnostic tool, the core Data::Dumper
to dump your data structures, or Data::Printer
to inspect complex objects.
All those allow to figure out causes in case something does not go as planned. Perl can also be run in debug mode with the -d
switch.
Comparing Perl to other languages
Python
Python has a built-in interactive shell where you can easily develop code and learn. It is amazing and helps newcomers to get to the point directly without having to configure an entire environment. It can also help evaluate quick statements and prototypes or just verify some syntax.
In Perl, interactive shells exists from CPAN. Such examples are Reply or Devel::REPL
, an effort to build a modern REPL.
A similar thing to mention from Perl world that might be similar to REPL environments and a part of its folklore are the Perl one liners, which are very short programs that operate on lists, whole file lines, can generate, replace, or encode for very little effort with very little typing.
A good reason why Python serves as an excellent learner’s programming language for that is Python isn’t a TIMTOWTDI language at its core. The fact that it doesn’t allow a wide variety of ways to implement something can make it more straightforward and make it easier. It is also well known for its “batteries-included” philosophy.
Python is an out and out object-oriented paradigm. Perl is a mix. Python offers several functional programming concepts like lambda, map, and friends, but it remains rooted in OOP.
Perl is more invested in using traditional references and hash semantics for subroutines and other advanced usage. Python tries to do it using objects a little like how Node.js does it.
Python has Jupyter notebook that takes the power of Python to the browser. Python scripts tend to be shorter than Perl in general. Python has more economic syntax, which produces excellent savings in lines of code by chaining objects.
Sometimes it is not an apples to apples comparison as each programming language has its own benefits and specific uses.
Node.js
Node.js is object-oriented and asynchronous in its core.
Its program flow requires a good understanding of non-blocking programming. Even experienced programmers struggle with code flow and figuring out when a function returns. It can lead to callback hell, though promises and async/await make things better—if they are used. But the event loop and single threaded Node.js flow makes it harder to use for one off tasks.
If you wish to use a third-party library to solve a particular problem, you can either do it using Node.js or Perl. The open source modules for plugging into most third-party libraries exist for both languages. Most of the time, Node.js relies on package.json and local installations of modules and Node.js. Despite Perl’s wide availability on most systems, this is something that Perl community tends to encourage with tools like perlbrew
, which allows the admin-free installation of Perl and separation of the system Perl (allowing to have many versions installed). perlbrew
is very similar to nvm (the Node Version Manager). Another interesting tool is Carton, a modules dependency manager, inspired by Ruby’s Bundler and similar to npm, allowing you to track, install, deploy, or bundle your applications dependencies.
ksh or Bash
Well, this is a funny thing to write. Perl could be a contender for shell-scripting jobs as it is a scripting language, correct? But Perl installation is a factor to consider whether to use it or some shell in a resource-constrained environment like Raspberry Pi or something.
A common opinion about shell scripts is that after more than a couple of lines, you should consider rewriting them in Perl, Python, Go, Ruby, or any high-level language you like that allows the use of libraries. This will help to handle daily task easier and avoid reinventing the wheel.
The future of Perl
Because it continued to evolve by taking it’s inspiration from other languages, it can provide production ready implementations for event loops, promises, object-oriented programming. In the last few years, the Corinna specifications and Object::Pad
implementation are preparing the introduction of modern OOP in the Perl core.
It is continuously improved by a large community and each release provide new features that take it to the next step. Notable examples being:
- v5.34 provides an experimental try / catch syntax and the perlgov documentation, exposing goals, scope, system, and rules for Perl’s new governance model.
- v5.36 provide non-experimental subroutines signatures.
A couple of years ago, Perl 7 was announced, which brings an end to the Raku / Perl confusion and proposes to bring the best of modern Perl practices to the front.
Why it is still relevant in 2022
Perl is not going away even if it tends to be less trendy than other modern languages.
It is used in production codebases of many companies, for tasks as diverse as web development, databases access, log analysis or web crawling. It is a core component of most unix-like systems.
Many legacy production systems rely on Perl and new Perl applications are flourishing using the modern Perl toolkits available through CPAN.
If CGI was an important historic part of the Perl culture until the mid 2000, it was removed from Perl core with 5.22 in 2014. CGI has been the recommended way to handle web development for a while; prefer instead the alternatives provided by he community. Two notable web frameworks are Dancer and Mojolicious.
In terms of bindings to other libraries and utilities, Perl is as good as other choices. For instance, communication with libcurl or libtls or some third-party open-source library or database can be achieved with any language we like. Here, Perl is supported out of the box and provide easy ways to get the job done.
Perl is perfectly capable of keeping up with modern trends. Code we write today is not the same as that which we wrote 20 years ago. Other languages have influenced the language as it became and we can expect that to continue and the ecosystem to grow.
Conclusion
Perl has always been very remarkable about its documentation and tutorials—perhaps being too wordy at times—but clearly they are developer-friendly.
Hopefully this article makes a case for Perl that is convincing and reasonably objective based on current trends, usage statistics, and developer base. A programmer is typically influenced by factors that differ from that of a business need or a manager. In both cases, Perl makes a case as it offers convenience, quick development times, and rich community support and tooling.
Tags: perl, unix
85 Comments
“but has undergone many changes since then (even spawning another programming language, Raku).”
Isn’t Raku just a renaming of Perl starting at version 6.0 of the language? That’s how it is described, anyway.
Raku was Perl 6, but they are considered separate, independently evolving languages. From https://www.perl.org/about.html
“”Perl” is a family of languages, “Raku” (formerly known as “Perl 6”) is part of the family, but it is a separate language which has its own development team. Its existence has no significant impact on the continuing development of “Perl”.”
Hmm, it sounds like Perl doesn’t know what it is then. From the paragraph directly before the one you quoted, it says “Perl is a highly capable, feature-rich programming language”. So it’s… a single programming language, *and* a family of languages all at once. And the folks here at SO (ostensibly the experts, I hope!) felt Perl 6 (otherwise known as the latest version of Perl) is renamed now to Raku, and that there is no more Perl moving forward (e.g. Perl refers to versions 5.x and older only), but the Perl 5.x-ers seem to not like that idea? Talk about a family feud! 😛
Perl 6 was announced in 2000 as the next version of Perl.
At some point around 8-10 years later, when it still hadn’t been released, the relationship between Perl 5 and Perl 6 was redefined to make them two different members of a family of programming languages.
This split was emphasised in 2019 with the renaming of Perl 6 to Raku.
Perl 5 is still in active development (although you wouldn’t believe that from the 20-year-old code in this article) and there have been conversations about what might, at some point in the future. become Perl 7.
Raku is also still actively developed but, as far as I can see, it has been struggling to get the traction it needs to be taken seriously in the industry.
Perl knows what it is. Raku knows what it is. Together they make up the Perl family of programming languages. There is no family feud here.
If someone tells you a piece of software is written in Lisp, they might mean CommonLISP, Scheme, Racket, Clojure or dozens of others.
These languages are all ‘Lisp’, as well as members of the family ‘Lisp’.
N.B.: Perl has all of the functional programming capabilities that make Lisp varieties so flexible; C, for instance, has none of them.
The difference being: those languages purposely split off to change some aspect of Lisp (e.g. namespace behaviour
). Perl tried to make the next version, but Larry Wall is such a terrible designer he got stuck in a loop for 10 years so they tried to retroactively claim it was always meant to be a new member of the family. Anyone who was around at the time knows this is a lie.
Some random thoughts:
Re: shell scripts:
The temptation to do a 4 line shell script to abbreviate some frequently done task is large. But anything more than a few lines, I do in Perl instead. Once you have to parse input parameters or do almost anything other than a quick pipe, it’s easier and IMO, *more readable*, to use Perl w/ system() commands or “ to get output into variables for further processing and feeding into further commands.
I don’t remember the last time I saw an OS that used bash, ksh, etc and didn’t also preinstall Perl 5. I’m sure there are some, I just haven’t encountered them.
Python is good, I use it now. It’s a bit painful, but it’s throwing of exceptions in cases where where perl might just give you a warning (that may get hidden in a log file) forces one to fix problems *now*. This is less of an issue if one religiously checks the return values of system calls, for example, but hey, I’m human.
There’s no excuse for the lack of “use strict; use warnings” in example code.
One thing I *really* miss in Python is lexical scoping in blocks, and being able to make blocks *anywhere*. Doing *everything* possible in functions, including main() , helps with this.
On the other hand, the “batteries included” philosophy of Python’s standard libraries is pretty cool. itertools and functools has a lot of cool stuff.
lambda is weak as hell compared to
{ do anything here }
Good article, always good to hear there are others like me out there. 😉
“When it comes to the performance of node.js and its event loop single-threaded performance, Perl is not a contender.”
I’m not sure I agree here – see EV and Mojolicious for some really good examples of Perl doing this just as well. You can write async perl just as easily as javascript. If that’s what you want.
“In the race for performance and modern trends, Perl definitely appears a bit dated. But it does have a place as we have seen above.”
Actually, I think the reason Perl still exists and that people still use it is because it is perfectly capable of keeping up with modern trends. Perl code I write today is not the same as that which I wrote 20 years ago. I’m pretty sure other languanges have influenced the way I write perl and I expact that to continue to be the case.
– Darrin
You’ve convinced me to switch to Python.
This comment made my day. 😀
Python is a language with bumpers and training wheels attached; sure you can do things, but it will look awkward and take much longer to get it done.
CGI for web application development in Perl is very outdated. Please see Dancer2 and Mojolicious for modern examples of web application frameworks in Perl, similar to Express in node.js.
I have experience with using Perl for CGI and Dancer2…. there is absolutely -NO- reason everything has to be done in Dancer or Mojo. In a lot of cases, Dancer is a huge overkill that is pushed on people to use just because its “the modern way”.
Each method and tool chain have their own strengths and weaknesses. CGI works for some tasks, Dancer works for other tasks. Use the right tool for the right job.
There’s also CGI::Application::PSGI if that’s more your speed. Or Catalyst if you want something much bigger than Dancer2. Or there’s Mojo. Or CGI::Application. Or CGI::Application::Dispatch. Or CGI::Application::Dispatch::PSGI. Or Amon2. Or Amon2::Lite which is pretty Sinatra-like. Or Router::Simple. Or Router::Simple::Sinatraish. Or Raisin. Or Router::Simple. or CGI::Builder. Or Routes::Tiny.
Or Jedi, Konstruct, Waft, Drogo, Attean, Puzzle, Eidolon, Maypole, Egg, Spike, Eve, Gantry, Kelp, WebNano, CGI::Mungo, Kossy, Titanium, Jifty, Limper, Weasel, Spoon, Sloth, PSGI::Hector, Tatsumaki, OX, Flea, Atto, Pepper, Ambrosia, Narada, Wallflower, or more frameworks besides Dancer2, Mojo, and Catalyst.
There’s Mason. There’s embperl. There are things as complete as Labyrinth or Captive::Portal, or apps like LemonLDAP::NG if that’s what you need.
Still, if you’re building new things to deploy at a decent scale, it doesn’t hurt to at least consider the top few options with the best docs, developer community, and support.
The fact that you think CGI is still the right tool for any job in 2022 is why you’re still using perl
Even the Perl 6 Raku people don’t like Perl 5. Perl 5 is a dead and dying language. Perl is overly complex and inconsistent. Even with CPAN you have to import hundreds of modules which leads to CPAN dependencies. Perl doesn’t always have Pro CPAN modules and they are second tier to Java or C++ and Python.
The inline Perl expressions make it tough to parse. IDE integration is a minus for Perl and other languages such as C++ have better IDE support.
Perl 5’s Oop is a total dumpster. There is no private or public and having to use hashes to reference an object is garbage. They should provide perl 5 with a simplified modern object framework not a bolted on hash interface. Perl hashes are not as powerful as C++ STL and Perl 5 had no concept of types.
C++ has way better Object OOP and is more modular and way faster. In some cases it’s 20+ times faster and easier syntax. Perl 5 is dead and even GO trumps it.
That is hilarious that you think python has better libraries… Perl’s quality and capabilities of libraries blows python out of the water everytime.
Nice article. Even though I more often reach for Python nowadays, I still have a fondness for Perl and will sometimes use it, especially if what I need to do is centered on applying regular expressions or using UNIX pipes.
I have a quibble: when you describe CPAN modules that offer both object-oriented and “functional” interfaces (and when you give your sha256 example), you mean procedural, not functional. However, when you later mention functional programming concepts in Python like lambda and map, that usage of “functional” is correct.
Can you share any resources link to learn Perl?
https://learn.perl.org/ would be a good place to start.
http://www.modernperlbooks.com/books/modern_perl_2016/index.html is the HTML, browsable version of the 4th edition of Modern Perl. You can also buy the paper book or download the ebook.
https://learn.perl.org/books/ has lots of introductory books listed including that one.
https://www.perl.org/books/library.html lists multiple books for which you can download the digital copies for free.
There are pages and pages of books on Perl at many used booksellers. Titles can be hit or miss and some of the material not listed above can be pretty dated. With that in mind, anything by Jon Orwant, brian d foy, Curtis “Ovid” Poe, Damian Conway, Randal Schwartz, Larry Wall, Tim Bunce, or Lincoln Stein should be good considering its age.
I highly recommend ‘Higher Order Perl’. That book alone puts to rest all the trash-talk about perl being good for throw-away simple script to replace a few lines of bash.
It’s frustrating to see this low quality article posted to stackoverflow. It posses a legitimate question then fails to answer it in a compelling way, using 20 year old poor quality Perl code in all the examples.
This is yet another example of a mediocre Perl developer that is either not beyond the surface in their knowledge or hasn’t kept up with the language for, oh, at least 15 years. Almost every sentence in the post contains either bad or out of date information. The author should feel bad.
After reading the article, I still don’t know why anyone would use perl.
Skip this article: The author did a pretty poor job of pointing out Perl’s strengths.
The 2018 edition of the classic ‘Camel Book’, ‘Programming Perl’ went with ‘unmatched power for text processing and scripting’ – even that is selling Perl 5 short.
Allow me:
* Perl has the BEST Unicode support of ANY programming language… (apart from Raku, that is)
* Perl’s regex engine is the most advanced, flexible and powerful of ANY programming language
* Perl gives programmers FAR more freedom than other languages – you can rewrite the language from top to bottom to suit your needs, or just tweak it
… just ask jwz – he can’t stand Python not having braces { }
* Perl is fast, with brilliant optimisations
* The CPAN is still full of fantastic, amazing, quality software
* The Perl community practically INVENTED software testing
… (and wrote loads of brilliant CPAN modules to do it)
* Perl allows you to augment its standard OOP with a huge variety of OOP libraries offering metaprogramming, types, lazy building… or just really terse classes…
* Perl’s modern web frameworks are second to none
… mature, powerful and learning from the best of other fave dynamic languages
Instead of this article, read:
– *Modern Perl*, by chromatic
http://www.modernperlbooks.com/books/modern_perl_2016/index.html
– the latest edition of *Learning Perl*, by brian d foy
https://www.oreilly.com/library/view/learning-perl-8th/9781492094944/
– the above and others can be found at https://learn.perl.org/books/ (as mentioned elsewhere)
I should add that some good stuff about Perl _is_ mentioned, but it is hidden behind ‘faint praise’, watered down with mistakes and obfuscated by outdated techniques.
The article is a perfect example why no one should be using perl if they can avoid it: it’s so bad and out of date that even people who feel compelled to promote it don’t really understand it. How many times has this article been edited? It was originally showing CGI code and had an exploit in it. Even people who love the language can’t write safe code in it!
That’s like saying I don’t know why anyone would speak French. It’s a great language in it’s own right even if you do but understand it.
“People talk of node.js streams and so on, but to me it looks like a joke…” This and other statements about node.js make this article seem like FUD to me
It’s great to see Stack Overflow publishing a positive Perl article like this. But it would be even better if it was written by someone whose knowledge of Perl wasn’t about twenty years out of date.
A lot of the code here looks really dated.
* No “use strict” or “use warnings”
* No declaration of variables
* Using ‘&’ to call subroutines randomly – it’s not needed in any of these examples
* Using CGI for web programming
* At least one example of “new Class” instead of the recommended Class->new()
* Using bareword (global) filehandles instead of lexical variables
* Two-argument version of “open()” instead of the, safer, three-argument version
Perl is a powerful, modern language. But you wouldn’t believe it from reading this article.
Correct point about the CGI.
What Perl lacks are ready-to-use programs that beginners could familiarize themselves with.
I tried to create something in the field of web programming. This is my CMS for a site on Mojolicious. Unfortunately, the code doesn’t look perfect because my knowledge of Perl is not systematic enough.
The link to my MornCat CMS: https://github.com/arslonga/my_blog
Exactly. It’s another bad article about PERL. Unfortunatelly. Please call the masters of PERL to write about PERL.
How about “Why Perl _is not_ and has _not_ been relevant for the past couple of decades” ?
And how about “Why no weakly typed language ever was relevant, for anything” ?
uhm, just because it’s not the case, that’s why
But the libraries are rotting.
Installing any significant library installs huge dependencies, with 0.0.1 version numbers.
Plus many of us will recognise Perl as a write-only language, in that if you don’t use if for a week or two, you’re back to re-learning what the line-noise means.
Thanks for giving a good example of the untruths programmers who don’t understand Perl trot out when they want to indulge in prejudice instead of find out how Perl can help them.
The CPAN has a fantastic quality ethic and processes and community support. Check out https://www.metacpan.org and look for all the ways preferred distributions are flagged up: distro upvotes; comprehensive testing reports; ‘Kwalitee’; issues tracking; bus number rating; excellent documentation (leading the Open Source community, in fact); browsable code…
Using lots of other libraries is a sign that the programmer *knew what they were doing* and how to do it without writing unnecessary code.
If you have never learned Perl, and don’t use it very often, then maybe it doesn’t look very familiar after a few months. No programming language exists that can be used effectively by a novice with no training to create bulletproof enterprise software.
There is no reason to “find out how Perl can help them”. There is nothing I can do in Perl that I can’t do in Python, Javascript, etc. There is nothing that CPAN has that isn’t available in other, more popular and modern languages. The quality isn’t better. There is just nothing compelling about Perl. What is compelling, though, is being able to find programmers to develop and maintain your system. And since Perl has all but died completely out, I can’t find people quickly like I can with more modern languages.
The code snippets of the “Bonus: Perl code you can use” section are pretty low quality. Just to point out a few issues:
– missing `use strict; use warnings;`
– `my $i; foreach $i …` instead of `foreach my $i …`
– useless initialization of arrays and hashes (eg, `@mailBody =();`)
– some variables declared earlier than necessary (eg, `my $IO;`)
– just a print instead of a die/exit after `if (!defined($db))`
– global instead of lexical filehandles
– use of `gt` instead of `>` for number comparison
– functions called with `&f` instead of simply `f()`
– useless hash copy in `%schash = %$dec;`
– …
In fact, this kind of Perl code is exactly the reason why people don’t like Perl: it’s messy, errors are poorly handled, it’s hard to understand, the lack of strict/warnings means that things will break at execution time rather than at compile time…
There is a good reason for ‘&f’ – especially in sub calls from within a sub – i.e. it means ‘call sub f with the same arguments as I was called’. And combined with ‘goto’ (yes, there is a ‘goto’ in Perl) one can write tail-recursive routines pretty elegantly. Try to write a recursive factorial routine and calculate fact(500).
Perl is only relevant as an example of what NOT to do when designing a language.
Will Hunting: “You got that from Matz….do you have any thoughts of your own?”
Pretty much all of Perl’s “pros” listed here are also present in Python, and a myriad other scripting languages. Funny how you glossed over Perl’s biggest “con”, which is that it’s absolutely unreadable.
As to your “Why it’s still relevant” points, those same arguments could be made about COBOL. Ancient Perl scripts are still up and running, yes, precisely because they’re so critical and undecipherable that nobody will dare to touch them. I never really see any new exciting projects being started in Perl.
I am not pro-Perl by any means but the “Perl is unreadable” trope was invalidated for me over two decades ago doing my first professional Perl programming (I’d learn it for CGI on the side) and, it seemed perfectly readable at the time, and still does those two decades hence.
Yeah, people like to parrot that crap line about Perl every chance they get. It gets old.
I’ve seen really clean and easy to read Perl code, and I’ve seen crappy looking Javascript and Python.
Anecdotes are not data. The majority of people who write perl can’t even read their own code if they’re away from it for anything length of time. That’s why it got the reputation.
“The majority of people who write perl can’t even read their own code if they’re away from it for anything length of time.”. That’s the very definition of an anecdote.
And it’s pure BS. Only really bad developers would have that problem. I worked on a big Perl project back in the early 00’s in CS grad school. It was a big NLP pipeline (that spawned off a company that’s still out there feeding hedge funds with data) and several students worked on it at various levels of competence. When it came time to pass on my part of the project to the next generation of grad students, I was messaged by one of them telling me they couldn’t believe how clear and easy to read my code was, and thanking me for that.
Well, yeah, I want my code to be readable in the future. Perl is more readable than several other languages if you know what you are doing. It is one of the languages that give you the rope to hang yourself, but you don’t have to take it!
In my current company we have a system in Perl and a system in Node.js. We hired 3 Node.js Junior Devs and taught them Perl to be able to work on the Perl system as well. At the start they felt quite uncomfortable and liked to do js stuff which they knew. Fast forward a couple of years later, NONE of them wants to work on the Node.js system anymore, they enjoy Perl more, it just took them a while to figure it out!
Much of the Nix tooling is written in Perl.
Try again.
Seems pretty similar to PowerShell, but less readable and less powerful. PowerShell integrates with operating system commands and fully supports piping and so on, but it also has .NET CLR code to fall back on if any additional functionality is useful AND is already installed in the operating system. It may not be as powerful in the CGI world, but who wants to use a scripting language when building a web server anyways?
Perl is already installed on pretty much any OS that isn’t Windows, while if I want PowerShell on Linux, BSD, or macOS I have to go get it. Perl supports piping fine, but it is the older Unix-style piping by default rather than objects. One would have to use a serializer/deserializer library to read and write JSON/YAML/some format to do the level of piping that PowerShell does, but that’s basically every non-PowerShell language.
No, Perl doesn’t support “piping fine”. Not the way Powershell does. Perl just supports parsing text and piping on unix converts everything to text. In Powershell you can pass real objects between the pipes. This is radically more powerful, though if you’re stuck using things like perl than you probably can’t see what this kind of power would give you.
Ugh. “already installed in THE operating system”…
PowerShell is a pathetic knock-off of Perl, but far less readable, far less powerful and v e e e r y s l o o o o o o w
… plus you are forced to use the badly documented and badly designed .NET class library, instead of the Perl community’s brilliant, clever, usable and fun distros from http://www.metacpan.org
And Perl isn’t “a scripting language”: it’s a general purpose, dynamic programming language, just like… er… the CIR that C# (for one) compiles to.
Perl is **great** for scripting, and **even better** for serious enterprise application software development. I’ve written web services with C#, and it was horrible.
Perl is better than PowerShell in every way, and arguably more flexible and powerful overall than C#, though I’ve met very wise Perl people who speak well of C#.
Perl is, and has always been, an excellent choice for building web applications.
Sorry, what I meant was: Perl is a general purpose programming language; it (like Python, Ruby and JS) is a dynamic interpreted language that compiles and runs on the fly, saving valuable developer time. Thanks to brilliant optimisations, Perl is still plenty fast, and getting faster.
The .NET IL that C# et al. compile to is also an interpreted language; you can code it in if you really want to, but I wouldn’t recommend it.
No it isn’t. Perl is not suitable for enterprise level software, who are you kidding? There are literally no large enterprises anywhere writing big greenfield systems in perl. None. There were a few in the past who did and it went badly enough that the rest of the industry didn’t follow suit.
And no, Perl is not suitable for modern web applications. A nice, cloud based web application today won’t even have a traditional back end. It will use something like AWS Amplify. So where does your Perl code even go?
I had to read the date of your comment 3 times because it seems like it was written by someone from the late 90’s. Hard to believe someone in 2022 is still living in such a bubble to believe anything you wrote here.
I would argue PowerShell is unreadable…
I disagree that Perl, in and of itself, is difficult to read. Any language can be written so poorly as to render it’s code unreadable at first glance. I recognize the deficiencies of this language and can understand why its popularity has declined over the last decade (or more). And perhaps this article is a bit rosey in its treatment of Perl. Yet the language is still used. New code is still written in Perl, just as new code is still written in FORTRAN. (Now there’s an old language.) I may be partial to coding in Perl compared to Python, but we can do most anything in either language. I simply prefer to do it in Perl.
FORTRAN has over half a century of scientific computing libraries and legacy behind it.
Why does your code look like it was written in the 2000s
Looks like he hasn’t kept up with the last twenty or so years of Perl development.
Among other problems, the biggest issue with this article is that it doesn’t even mention Ruby as a competitor. Any situation where Perl would be a better choice than Python, Ruby fills that niche even better IMO, as a language that took Perl’s text munging and combined it with Smalltalk’s OO model (and got rid of Perl’s notable warts like sigils and implicit args).
Perl is probably a good choice for you because you’re familiar with it, but that’s a different question than what language is good for someone else to pick up.
Er, Ruby has sigils? If you don’t like the way they work in Perl 5 – which, by the way, is actually quite straightforward and sensible – then try Raku.
Perl’s text munging – in particular, Perl’s regex capabilities and Unicode support – are outdone only by its little sister Raku, which is incredibly powerful.
Perl’s toolchain used to have the edge on Ruby’s when it came to installing modules. If the Ruby community has done the hard work to get back in contention, good for them.
It’s nice to see that Stack Overflow is willing to publish something positive about Perl, and I’m grateful to the author for taking the time to write it, but I am sad about the lack of quality in this article. It makes me wonder where the quality control has gone. I expect to read articles that are much better edited on an official blog by a company such as Stack Overflow.
Others have already pointed out what’s bad about this article, so I would like to focus on the community around Perl on Stack Overflow.
There are not many new questions in the Perl tag compared to other languages. At the moment, we get something like 5 a day on average, with the weekends being quiet. Almost all of them get answered, and most of them get accepted. A lot of questions are fairly entry level, and often by new users. It’s common that a new user will ask a series of questions to figure out a given problem, and the quality of their questions often improves significantly while doing this.
Then there are users who have been around for many years, and every so often they ask a question that takes a little bit of research to answer. It’s always nice to see one of these, because it reminds me that there are more professionals out there going about their jobs, and that they come and seek the experience of other like-minded people, just like me.
Finally, we have the group of regulars, the experts who answer most of the questions, often within a few hours. There are probably about 5 very active ones of us at the moment, and about 10 in total. Many have been active on Stack Overflow for a good 10 years, but some are much newer. We count a few 100k users among us, and there are CPAN maintainers, published authors of Perl books and even a few regular contributors to the Perl 5 core itself.
If you have a Perl problem, you will usually get an answer here. It will be professional, constructive, concise and modern, often pointing out further improvements to the code in the question. I think I’m not alone when I say we do this because we enjoy Perl and we enjoy helping people get better at it.
It would be nice to see all of this expertise be called upon before something gets published under the official Stack Overflow banner.
It also would be mean to assume anything but good faith, so i’d like to extend to the author an invitation to help him learn more about modern Perl. A lot has happened in the last 20 years that you haven’t seen yet, I believe. Get in touch, and we’ll show you.
I rely on pitches from external writers for articles like this. If you would like to improve the quality of articles by pitching one of your own, please email me at pitches@stackoverflow.com.
We started a community review of the article so that Girish could provide a second version of the post.
The comments are funny. “Perl is unreadable” and doesn’t do this or that.
It does (or did) do the routing between satellites in the Iridium project. It was involved in satellite control—course correction, detection and so forth.
Perl, using Mario Roy’s MCE, checks millions of devices at a huge cable company. It does so in under four hours while the previous java code took a day and a half.
Perl is still relevant but is out of fashion. This is the true problem with it.
I’ll admit that I’ve been spoiled by modern, easy-to-read programming languages, but I did try Perl and found it unutterably unreadable and after endless weeks cutting my teeth decided to go back to my cushy life writing x86 assembly grateful I don’t have to work with such unreadable line-noise every day.
Your sample perl code has XSS vulnerabilities because untrusted From and path names are not escaped in the HTML output. You should look into the HTML::Escape package.
I’ve used Perl since 1995 before php, python, node etc. were a twinkle in their creator’s eye. We still use Perl today for all our web based programs. Combined with Javascript and MySQL database we can create powerful programs. For me one advantage of Perl over say PHP is the separation between program code and web page.
I’ve no doubt that some modern languages might be easier to understand but but will they add functionality to the programs we create, so far the answer is no so why change.
The best reply and i agree. Thanks.
Talking about processing speed seems irrelevant to me, as we have ultra-fast and increasingly faster hardware now a days.
I see that PERL bothers the business that sells “new” (meta) programming languages… some of them will be extinct in 10 years and PERL as well as C will still be alive and active.
The software industry needs to make money by creating “new” things or making up the old ones.
It would be more productive to improve what already exists and works wonderfully, but it wouldn’t yield as much $$$$.
Uh, hardware is not increasing all that much. I’m in the process of replacing a 10-year-old desktop with a new one, and the new one is only barely twice as fast in single-threaded performance..and maybe two percent faster in terms of memory. The only really major improvement is the NVMe drives it has…and that doesn’t make as much difference as you’d might think. Most of the gains in storage speed were from access time and IOPS, which a SATA-based SSD can handle fine.
In 2032 (well, 2030 really, I’ve been sitting on these parts for about two years now), I’d not be surprised to find out the newest CPUs aren’t even 30% faster than the system I’m building today.
Compare that to the 80s when you have things like 68020s replacing 68000s and 80386s replacing 80286s and ‘286s replacing 8088/86s – those were BIG leaps in much shorter time!
Moore himself noted that his ‘law’ wouldn’t hold up forever. He was right.
I don’t use PERL in any production-level code, but I do use it extensively for ripping through multilevel directories to convert various file types (txt/xml/pdf) into a form I can use (i.e. sqlite) in mobile apps. Perhaps there’s better ways to do those kinds of tasks, but since the Practically Eclectic Rubbish Lister comes pre-installed with MacOS and has a pile of available libraries, I’ll keep using it.
The main problem of Perl is the difficulty to be converted to javascript or php.
Hmm, not sure why you’d want to ‘convert’ Perl to either of those inferior languages.
JS is improving, and it is very likeable, but at its heart still shows the scars of the fact that Brendan Eich had to hack it together in a few days. I still haven’t quite got my head round prototype-based OOP. And when you’re used to the effortless simplicity and power of Perl’s regex matching and substitution ‘builtins’ (core functions), JS’s native Regex object is a chore to use.
(Quick reminder: other popular languages tried to ‘borrow’ Perl’s improved regex pattern syntax, but only bothered to implement about half of it, the most commonly used bits. You have to use Perl to get the real power, AND flexibility.)
As for PHP: even its own developers acknowledge its many flaws. PHP started off as a hacky knock-down version of Perl, which seems to have mostly borrowed the look of Perl, but not the power or flexibility.
This classic article explains how bad PHP used to be and largely still is: https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/
A long time ago someone put it about that PHP was ‘easy’, and teenage script kiddies found it was a way to get honest work. In comparison, Perl was said to be ‘hard’. This isn’t true, but the lie stuck, a bit like those bits of used chewing gum you find dotted about on the seatbacks of public transport (a.k.a. mass transit).
PHP 8 is still trying to play catch-up with the many far better languages it puzzlingly continues to rub shoulders with. But it remains mired hopelessly in its “script tag” origins, harking back to the days when web apps were just bits of code written into webpages. Now there’s a language that can’t break free of its past.
The problem with Perl is that it’s a write only language. It has too many terse forms of constructs and just in general has solved too many “problems” in all the wrong ways. Larry was a good guy, but Perl was just not a great fit for many things because of the write only nature of it. It would take way to look to look at a Perl program and digest how it worked. It is much easier to write a shell script where the number of “operators” is small and the effects of the constructs is very visible.
It’s a shame you can’t downvote comments on this blog the way you can downvote them in the actual Q&A forum bit!
You don’t like Perl’s terse nature, but you prefer, erm, Bash? Where even writing an if statement is painfully cumbersome and operators are abstruse with too many symbols and a clunky syntax?
All the bits of Bash syntax that are worth keeping went into Perl anyway; the rest were either improved or replaced.
You don’t like Perl’s concise special variable names? Fine – just put `use English;` at the top of your script.
You can look up the variables’ symbolic, short English and full English names in `perldoc perlvar` you know…
And a lot of the time you don’t need to use them at all.
“You don’t like this horrible thing about this archaic language? Well just put these 50 lines at the top of your script and it will be almost as good as just using Python is”
Great argument dude
use strict, am I a joke to you?
I still prefer PHP (CLI)
You can see in the comments how the writer is roughly corrected- it’s a common phenomena in the Perl universe from my experience
I worked at a company writing Perl and all the stack overflow answers I found would be 10+ years old and Nasty! Don’t even talk about perlmonks 😅
Perl makes regular expressions easy- they become cumbersome to do in other languages when you’ve done them in Perl. De referencing was annoying. Reading another developers code in Perl often was more challenging (to me) than say any other language. I liked the ability to dynamically generate variable names easily without doing something taboo like eval(/*code*/) in javascript or globals()#code in Python.
I also liked its secret operators because they made me feel cool 😎
https://metacpan.org/dist/perlsecret/view/lib/perlsecret.pod
A good read is the manual… “perl programming” by Tom Christiansen. My favorite software book for his fun writing style.
But if you have a question Dont be surprised if Google takes you to some +10 year old post questioning your life decisions on perlmonks or SO😅
Perl did its job for the 90s internet and other software development, etc:
1) contributing some syntax-related influence to PHP and PowerShell
2) contributing a very tiny aspect of how modules work in Python
3) encouraging programming language developers to make their languages more user-friendly
4) pondering programming in a form of scripting language that is extremely complicated
I passionately and personally hate Perl but I only respect its contribution to the programming world.
Perl will continue to decline at the same pace at which companies and projects that were once started with Perl die out. No faster, no slower.
Almost no one is starting new projects in Perl, because Perl does nothing noteworthy that other languages don’t do better.
regular expressions