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

On the Decline of Perl [internal factors]

Thread Next
Paul "LeoNerd" Evans
March 28, 2021 00:00
On the Decline of Perl [internal factors]
Message ID:
Here too is a copy of the second half; split into a separate thread for
reply purposes.


Lets now focus instead on some internal reasons why we might observe
that "perl is declining". These mostly focus on a lack of people. (I
was going to write "manpower" but I don't know a suitable
gender-agnostic alternative, sorry).

Perhaps others have noticed this as well, or maybe I am the only one,
but I feel we are *seriously* understaffed in actual Perl Core land, in
terms of who is around and technically able to write features. I'm not
talking those who have permission by way of a commit bit. I'm talking
about the count of people who actually know what it is they are doing,
to bring a nontrivial amount of new code to implement some new syntax
or semantics into the language.

A few years ago when I first started dabbling in code which might
interact with core (by way of some CPAN modules adding syntax like
try/catch or async/await) I found myself often asking questions on #p5p
to which nobody knew the answer. There was a particularly notable
moment when, at TPC in Glasgow, I asked Nicholas Clark a rather obscure
question about the innards of the perl interpreter context stack. His
response was to say that if anyone else had asked that question, he
would have referred them to me. That I think was the first moment I
realised that there may have been *nobody* around who knew the answer
to my question. Without an answer to that question, Future::AsyncAwait
would not have been possible, and Perl would never have gained
async/await syntax.

  (<Narrator> An answer was eventually found by much research
    and reading of code, and thus the module did become possible.)

Last year there was a push to bring the core perl files a bit more up
to date, at least to ensure that all the core unit tests are
strict/warnings safe. Even right now I notice several that are not. Why
have we not kept our own house in order, even to the point of
`use strict + use warnings` in every file? Again, lack of people/time
to do it.

I continued to find it more recently when implementing `use feature
'try'` that, in practice, hardly anybody knows a lot about the entire
sweep of changes and additions that must be done, in order to bring
nontrivial new features into core perl.

Outside of core, I have recently been working on my TPF grant project,
to make a libuv binding [because, of course we the Perl types have to
do that - see my previous comments about external 3rd party libraries
not doing that for us any longer]. This time, the trouble I am finding
is the lack of Win32-specific experts to ask portability questions to.
I'm currently developing it blind, by basically fiddling with code in a
way that /might/ work, then releasing another TRIAL tarball to CPAN in
order to see if the Win32 smokers like it or not. Does that sound like
the way that major library bindings for a major language should be
developed in the 21st century? To me it does not.

Maybe this is why hardly any core feature development have been done in
a long time, leading to the external view that perl has stagnated.

What new features can we actually say have been added since... lets be
generous. Since 5.10 - that's 14 years old now. Here is my list of all
the exciting things I can think of ever since 5.10, with the most
exciting first.

  Signatures - 5.20ish.

  try/catch - 5.34  [though I'm biased because I wrote it]

  postfix deref - 5.20maybe?

  /r flag on substitutions - 5.14ish? I forget.

That's kindof all. And honestly, I don't think I'd be shouting out loud
about any of those. Not to say I don't immensely appreciate the
signatures feature, for example. Just that all four of those are really
just playing catch-up, adding to Perl such features that basically
every other competitor language has prettymuch always had. If you
posted right now any of those things to Hackernews with "Hey, look at
what Perl can now do" honestly I think people would laugh at you and
say "What, you mean it couldn't before?".

This is the reality of the situation we are in.

If we are wanting to look at why Perl is declining, we must address
this fact, however uncomfortable it may be, that a significant factor
of that decline is the almost-total stagnation of core features around
a point that wasn't even state-of-the-art in the 1990s, and is only
just now picking up as "headline" features abilities that every other
language was doing from the beginning.


[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