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.
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.