https://two-wrongs.com/why-perl.html

Two Wrongs

Why Perl?

  * Home
  * Tags
  * Feed
  * About
  * xkqr.org

Why Perl?

by
kqr
, published 2023-05-28
Tags:

  * programming
  * meta_programming

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[ ]^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:

 1. It is installed by default everywhere. I don't need
    administrative privileges to deploy Perl code almost anywhere.
    That is extremely empowering.
 2. With a great amount of discipline, Perl scripts can be
    successfully scaled up into large, complex systems.
 3. I can be confident that a Perl script I write today will run
    unaltered 10 years from now, modulo external collaborators.
 4. Perl can be used nearly as a shell replacement for very quick
    scripting.
 5. 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[ ]^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 | Compatibility |  Shell  | Extensible |
|            |          |   up   |               | scripts |            |
|------------+----------+--------+---------------+---------+------------|
| 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

2023-04-20: 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.

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

Sidenotes

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

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

Comments? Send me an email.
I will publish your comment on this site as soon as I'm able.

 

You can also show your support by buying me a coffee, iff you want
to.

Shoutout to my amazing wife   without whose support I would never
make it past the first sentence.