Why Perl?
I sometimes get asked why I use Perl so much. Am I not a fan of strongly typed functional programming? Yeah, I am. Ask me to write something that is known, for sure, to become a big system and I’ll pick strongly typed functional programming without hesitation.1 And, of course, put me in a team that uses Blub, and I’ll pick up Blub in a heartbeat. Except php. I tried to give php an honest chance recently (“It has changed”, they said, “It is much better with modern practices”) but it was painful all the way through, even when I tried to do everything right. But most of the software I write is not for sure going to become a big system. Here’s what Perl does well:
- It is installed by default everywhere. I don’t need administrative privileges to deploy Perl code almost anywhere. That is extremely empowering.
- With a great amount of discipline, Perl scripts can be successfully scaled up into large, complex systems.
- I can be confident that a Perl script I write today will run unaltered 10 years from now, modulo external collaborators.
- Perl can be used nearly as a shell replacement for very quick scripting.
- Perl has a small set of core syntax and is very extensible and flexible in adopting new paradigms.
These requirements are listed in priority order. The most important consideration is ubiquity. When throwing out a quick prototype, I don’t want the deployment instructions to start with “First install a development environment.”2 What about containers? Maybe. I’ve had mixed experiences with that. If nothing else, it adds a lot of extra … stuff to what should be a small experiment. Since prototypes always outlive their intended lifespan, it is also very important that it is possible to write maintainable software in the language, and that it will keep running for as long as someone is interested in running it.
Perl is unique in fulfilling these requirements. Let’s look at some other alternatives I’ve considered for this role, and tried to use that way for at least a month.
| Language | Ubiquity | Scales up | Compatibility | Shell scripts | Extensible |
|---|---|---|---|---|---|
| Perl | ✅ | ✅* | ✅ | ✅ | ✅ |
| Python | ✅* | ✅ | ❌ | ❌* | ❌ |
| JavaScript | ✅* | ✅* | ❌ | ❌ | ❌ |
| Bash | ✅ | ❌ | ✅ | ✅ | ❌ |
| Common Lisp | ❌ | ✅ | ✅ | ❌ | ✅ |
| Java/C# | ❌ | ✅ | ✅ | ❌ | ❌ |
| Haskell | ❌ | ✅ | ❌* | ✅* | ✅ |
| R | ❌ | ❌ | ✅ | ✅* | ✅ |
Asterisk means borderline passing or borderline failing grade, depending on which symbol it is attached to.
Now is the time to admit that the real requirements are just the first three. That it’s convenient for quick scripts and adaptable around new paradigms is a small bonus – but as we see, Perl is unique also in fulfilling the first three and beggars can’t be choosers.
What about Ruby, Raku, F#, Scala, or Prolog? I haven’t actually tried any of them in this role for any extended period of time, so I don’t want to pass public judgment. What I do know is that none of them are as ubiquitous as Perl, which is the primary requirement.
Referencing This Article
Comments
: Nick Boyce
You should mention the big downside of Perl, which is that many people brought up on traditional procedural Algol-family languages believe Perl is a write-only language. At first sight the typical highly-useful piece of Perl code is completely incomprehensible, and this presents a maintenance problem.
: Eugen Konkov
Yes, Nick Boyce. I agree with you. Perl is a write-only language: I write the code once and then forget about it. I do not need to return to it for maintance. It works for years. Which is not true for other languages. More seriously, Perl code is also easier to read and understand. It has only few concepts I need to know. And has many excellent tools for testing, profiling, debugging and coverage analysis, which other languages do not have.
: Patrik Grip
I would argue that Perl is no more a write-only language than any other. The basic syntax for Perl is very clear and easy to understand for anyone who has programmed in a language in the Algol family of languages. What most people think looks like line noise are the regex parts. Which looks just the same in any language. However, they were to a large extent pioneered as an integral part of the language in Perl. And, yes, regex are in many instances write-only.
Certainly, there are some quirks in Perl, but even languages like Python, which is being heralded as the most readable language ever, have constructs and syntax that are very hard to understand for those that aren’t familiar with the language.
: Bruno Meneguele
Any language can be write-only if you don’t follow best practice guidelines; that’s one of the reasons that most open source projects out there has their own “coding style/standard” document. What I want to say is that it’s not a Perl-specific problem. This story is basically a meme due to the number of oneliners people used to use in the early stages of the web, which were required to be as terse as possible, and which holds true for those using Perl for oneliners nowadays, as Chris mentioned in the article as being one of the factors for choosing the language. Another big factor that elevated Perl as write-only language was the “Obfuscated Perl Contest” held in mid-90s and people though it would be a good idea to use some of the techniques on their real projects (:facepalm:).
I’ve worked with C code in the Linux kernel3 Editor’s note: Meneguele was a kernel maintainer at Red Hat for six years., and even with a really strict coding standard you still have to review a lot of functional, but nasty/ugly code. Personally, I think that Java code requires far more time and exhaustive analysis to understand than Perl ever required, even when I was learning Perl for the first time. Write-only code is present everywhere, mostly on those projects that were never planned for reaching a certain complexity or community size. Again, that’s not a Perl-specific thing.