Long Live Perl!
Still the Gold Standard
“Perl is for old farts,” some say.
Well, I definitely am that. I actually learned the language very deeply, in fact, I wrote the classes pragma, which is certainly a testament to the valid (albeit hypocritical) “read-only” criticism of the language. Looking back I realize any attempt to make Perl into an object-oriented language was frankly just missing the point—and original goal—of the language.
But, my young friends, Perl is still also for very astute systems and security coders who want a subtle, decisive edge over everyone else—be it in capture the flag, or in life. Let the uninformed diss the language—while you completely and utterly own them. True technologists evaluate the technology, not just the trend.
Here’s why.
Perl for Dot Files
So I was cleaning up my dotfiles based on clear directions in the industry (notably away from Python [which really is “snake oil” at the end of the day] when I remembered how many one-line Perl scripts I had in my profile.
As any forward-thinking technologist and educator would do I struggled over the question as to if I should keep them as Perl, port them to Bash, make them into commands in Go, or just leave them.
That’s when I was forced to realize Perl was—and is—the best regular-expression-based, shell-scripting interpreted language on the planet.
Perl was Made to Replace Sed and Awk
Most people do not know anything about Perl or its creator, Larry Wall, a brilliant linguist and man centered on saving the world through technology. Ironically, if they did know about him they would find they have a lot in common with him—especially the modern Millennial generation.
Perl Leverages Context Instead of Shunning It
Overwhelmingly the reason people love and hate Perl is because it leverages the context of every symbol and element to reduce the amount of code that must be written. This allows Perl to be written in perhaps the most dense, terse way. Even to Perl programmers one persons one-line of majestic artistry is completely unreadable to others.
But here’s the thing.
Sometimes you DO NOT NEED TO READ THE CODE LATER!
That is utter heresy in most coding classes (as it usually is in mine). But those classes—often with enterprise influence—are teaching you to be a good-little coder who can play well with others.
THIS is why Java and Python won because they promised to force everyone into conformity so that at any moment any of the programmers could be replaced by another—which is a solid requirement if you are trying to run a company. You should definitely think of the coder maintaining your code after you in that environment, and no, I could not recommend Perl for that (unless it is the only thing you have, which is why perl-classes was born).
Here are some cases where speed of writing code outweighs code maintenance:
- Cybersecurity (RedTeam Operations)
- Ad hoc shell scripting for singular operations
- Benchmarking and stress testing
For these things Perl completely and totally dominates, for reasons explained below. This is the reason all of the Metasploit exploits DB was originally in Perl and then ported to Ruby, which took root during the age of object-oriented insanity.
When do you know you should not use Perl?
- As soon as you need anything from CPAN
- If you reach for objects at all
- When you need concurrency in any way
- Your code will become part of a larger project
Perl is On Everything
People forget that Perl runs on everything better than Python or Ruby. It is on any Linux/UNIX computer by default created within the last 20 years and is fundamentally built into the git tool itself.
Perl Was the #1 Glue/Web Language for More than a Decade
It is no surprise given its flexibility that Perl was adopted over C for the Common Gateway Interface (CGI) code used to provide server-side functionality for web sites.
This usage has long since stopped being a thing. In fact, server-side scripts in general have stopped with #serverless and JAMstack now.
Perl is Not an Object-Oriented Language
Perl was not designed, at all, to be an object-oriented language, but every language was essentially forced to add some sort of OOP during that time. This is about when Python bolted objects on top of dictionaries (which are way slower than just a dictionary by the way). Python just happened to do a better job of the OOP approach and therefore, rightfully, won the enterprise market.
Perl 6 Fail
People say Perl 6 was a fail, but no more than Python 2–3. The major difference is that Perl 6 was years before the LLVM languages were even an idea. The designers of Perl 6 were a solid decade ahead of their time and laid the ground work for what became the LLVM architecture upon which Julia, Crystal and more “modern” languages are now built.
Perl Standardized Regular Expressions
To this day you can find perlre.so and other variations of the standard library for regular expression parsing. To anyone paying attention it is obvious Perl set the standard. Python, Ruby, Go and other language literally depend on this for their existence.
Perl Replaced Sed and Awk, That’s All
Perl—even Perl 4—is still overwhelmingly the best at what it initially set out to do as its primary goal: replace sed and awk which were highly inefficient requiring them to be fired up in their own subprocess every time dramatically showing down shell scripts involving heavy processing of configuration and data. Hence the “Practical Extraction and Reporting Language” acronym, which came after the fact.
Basic Perl Has Not Changed
The syntax of Perl 4 is still valid and remains on everything. There has been no backward breaking change.
Perl is Fast to Write
To a skilled shell programmer Perl is way faster to write than the equivalent using either Bash + Sed + Awk, Python, or Ruby. More importantly, however, the resulting program will run on any UNIX/Linux system built within the last 20 years. None of the other languages—including Bash—can claim that.
Perl is Fast to Execute
Since Perl doesn’t futz around with bytecode Perl executes much faster than both Python and Ruby. After all, it was designed to do so. Leaving bytecode littering a system is not only just bad design—it leaves breadcrumbs for those who are not careful and do not want the code execution known to others.
Who Cares If It Isn’t Popular
Sometimes objective conclusions are seriously unpopular. For example, I actually read a job description that read, “has a healthy disdain for Perl.” In light of the objective facts these snarky comments show how utterly moronic and uninformed those people are. It seems emboldened morons are the norm these days.
As for me, well, I will continue to out code them all and teach my very select group of students the secrets that others sheeple will never know. When they do things the others cannot dream of doing they will simply be left to wonder, “How did he do that, that fast?”
