develooper Front page | perl.perl5.porters | Postings from March 2021

On the Decline of Perl [external factors]

Thread Next
Paul "LeoNerd" Evans
March 27, 2021 23:59
On the Decline of Perl [external factors]
Message ID:
I recently wrote quite a long epic addressing the subject of whether
"perl is in decline", and if so why, and what we might do about it, on
the perl-core@ mailing list. It has been noted that that wasn't really
the correct venue for such a topic and being a closed list not many
people could write a response.

So here it is again in full. Apologies to folks who've already read it
once - this is an exact copy/paste of the whole thing unedited. I'm
reposting it here to give it a wider airing and to let several folks
who have responded to it in private have an opportunity to reply in
public if they wish. I will follow up some further replies and
observations after that.


Externally we could look at the fact that it feels like there are fewer
projects around using Perl than there used to be. I'm not sure where
we'd get hard stats on those, but that's a common feeling. I'm not sure
that Perl is any worse off here though than basically any other
language that isn't Python or maybe JavaScript. I may just be
remembering oddly, but I'm sure there was a time a couple of decades
ago when prettymuch any operating system feature, platform library, or
3rd-party integration wasn't considered "ready" until it had a few
highlevel language bindings - Perl and Python at least, possibly some
others like Ruby. Generally it was something like those three. GTK was
famous for having something like 18 *officially* supported languages,
and a total of about 40 by including the nonofficial ports. Crazy.
These days, paradoxically, while there are many more languages to choose
from, in practice far fewer of them receive such first-party support
from OSes/library vendors. Most likely you'll find a Python binding, and
that's about it.

Stepping outside the Perlish echochamber for a moment into my other
field of work, lets take a look at the world of electronics. I spend
quite a lot of time working with computer-based electronics tooling of
some kind or other, whether it's drawing PCBs using KiCad
[], inspecting test output from a logic analyser
using Sigrok [], or even writing and running code
directly on some sort of embedded CPU. And guess what - wherever we
look around here we find Python. And it's always Python. KiCad has a
scripting engine for automating boring repetitive tasks - it's Python.
Sigrok lets you write custom protocol analysers - in Python. And even
some microcontrollers now allow you to write code to run directly on the
chip in, while not exactly Python, a derived language called
micropython which is basically the same syntax minus a few features.

It's not hard to see why. Back a couple of decades ago, there were
basically two languages you could reasonably support for things like
this - Perl and Python. Most devs on your OS or C library team probably
know at least one. So you can support both just fine.

There's a thread [1] going on Hacker News currently linking to this
email thread. There's a lot of good quotes in it but relevant to this
part I'm going to copy this one:

  "Perl deserves credit for being way ahead of the curve: It was a free,
  widely available, garbage-collected language with good support for
  strings, during a time when the server-side alternatives were
  basically (primitive, early) C++ or expensive commercial toolchains.
  By 1995 it also had CPAN, which was (I believe) the first
  comprehensive directory of modules available for a language ecosystem.

  "The combination of garbage collection, good string support, and a
  huge set of easy-to-use third-party modules made Perl insanely
  productive relative to the other options at the time. Remember -
  Python didn't release a 1.0 until 1994, and Java 1.0 didn't come out
  until 1996, and the early versions of those languages were missing a
  lot of features you'd recognize today, and still had plenty of bugs
  and performance issues to work out. By 1994 Perl had been out for >6
  years, and reached version 5.0 that year. In both capabilities and
  maturity, it was ahead of the other free alternatives, and way ahead
  of trying to wrestle with string templating in C or C++. Perl enabled
  a ton of cool things to be built much more quickly than they would
  have with the other tools available at the time."

   -- alexhutcheson,

These days there's just so many more to choose from it's less clear
which ones you would pick. In practice, Python has snowballed simply
because of network effect. Everyone knows Python so everyone uses it so
everyone new has to learn it.

  "I think the problem is, more simply, competition. Now that Perl
  isn't the only reasonable dynamic language (you have ruby, python,
  nodejs...), people have more choices, and are ultimately just going
  to use what they already know as a 'plumbing' language."

   -- qsort,

Perl was (20 years ago) one of only two or three languages in its space
- the other and only main competitor being Python. The town was big
enough for two of two to both win. It is no longer big enough for two
of twenty to win. Given so many other languages in the same space now,
there can only really be one "winner".

I will conclude this section with an analogy I once saw for a similar
concept explained in terms of spoon colours. In some crazy world
wherein it would be useful if everyone picked the same coloured spoon,
it turns out we all use green spoons. Why green? Dunno, it's pretty
arbitrary. I'm sure the makers of red spoons and yellow spoons and all
the other spoons are pretty annoyed about it, but in the end it doesn't
matter. All the colours of spoon are just as good for eating soup,
but one colour had to be picked so we'd all use the same one, and it
turned out to be green. Perhaps we (the Perl core) are sat here
trying to sell our blue spoons, and wondering why nobody wants to buy
them any more. Do we want to turn our blue spoons a little greener, and
make them less distinctively blue in the hope of making them more
attractive? Would that help?

Does the colour of the spoon really matter that much, or is it simply
that everyone wants the same colour, regardless of what it is? Do we
want to throw away what makes our blue spoons distinctive blue colour
just to get in with the "in" crowd, even though we don't actually like



[from here I will make a reply responding to these factors with some
suggestions about what might be done about it]

Paul "LeoNerd" Evans      |  |

Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About