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

The current state of perl

Thread Next
From:
neilb
Date:
March 12, 2021 19:52
Subject:
The current state of perl
Message ID:
3cc65172-79ff-4317-89d1-8d86fb968b5d@Spark
When you're trying to work out where you want to get to, you need to agree where you're starting from.

This is a list of things that the PSC agreed we can take as fact, or that we're fairly confident of, with respect to the current state of Perl:

- Perl has a reputation for backwards compatibility, established & reinforced over decades.
 - There's a lot of Perl out there being used that was written more than 10 years ago, and is running unchanged.
 - There are people out there running versions of Perl between 5.8 and 5.32.
 - Perl has been in steady decline for a number of years.
 - We don't know all of the reasons why companies and people move away from Perl
 - Many features introduced post-5.8 aren't widely used
 - People aren't sure which features came in which version of perl, or whether they have a guard.
 - To a close approximation, we all stand on the shoulders of CPAN
 - Many CPAN authors target earlier versions of Perl for CPAN than they use
 - We have no way of knowing which CPAN modules are used, and which aren't

Let's expand on some of those.

What people mean by, and expect from, backwards compatibility, varies. There have been a number of breaking changes over the years, but a lot of effort was put into only doing those with good reason. There are people who think we've had too many breaking changes, but a lot of code written more than 10 years ago will run unchanged, and we think people have an expectation of that.

We know, first hand, that there are people with 5.8.x, 5.10, and 5.12 in production, and the subsequent versions. We've heard that there are people still using 5.6, but we've not heard that first-hand. Looking at various indicators, we can be confident that 5.6 through 5.12 or so aren't very widely used. Usage grows through 5.14, 5.16, 5.18, and the next 5 releases are probably where the bulk of users are. 5.28 and 5.30 are almost certainly more widely used than 5.32.

We have no way to accurately measure the number of active Perl developers, or the number of people using apps written in Perl. But we have a number of proxies, which taken together give us a consistent picture. For example, the number of people signing up for a PAUSE account has declined steadily over the last 6 years, as has the number of people releasing things to CPAN (post). Many of us know companies that have moved away from Perl, and have friends who've given it up. Conference attendance has been dropping. Some of this is down to the natural tech fad-cycle. There are a lot more programming languages to choose from now, compared to when Perl had its dynamic web heyday. There've been plenty of opinions expressed about why companies and individuals have left Perl, but we don't have a definitive model for that, but part of it is no doubt because of the observed decline.

A lot of features have been introduced since 5.8, but usage of them varies widely. This is based on anecdotal evidence, and our own personal experience, but given some of those anecdotes are from Perl veterans, we're pretty confident of this. Some of this is by definition: if they're running 5.12, people can't use features introduced later. But we know people who are running 5.28 who aren't using features added post 5.8, for a variety of reasons.

One of the reasons for this is that a lot of people aren't sure when a change was first introduced, and in which versions of Perl it's experimental, or feature-guarded, or built in.

If we assume that people who release modules to CPAN want them to be used by others, then given the above facts, it's not surprising that CPAN authors generally don't use features that have been released in the last 10 years. The toolchain currently aims to support 5.8.1 and up.

The previous few points mean that even though Perl has been evolving for the last 10 years, it's easy to feel that it's stagnant, or that the improvements made in the language can't be built upon in user code. And that will have contributed to the decline as well.

We have no way of knowing which CPAN modules are in active use. We have the River of CPAN, but that just tells us which CPAN distributions are relied on by other CPAN distributions. It's useful information, but there are plenty of widely-used modules with no CPAN dependents (e.g. in the App:: namespace), and there are no doubt CPAN distributions with multiple dependents that aren't used by anyone. Why is this relevant? It's tempting to say that we don't need to worry about breaking large swathes of CPAN, because we don't think anyone's using them (69% of CPAN distributions aren't used by any other CPAN distributions).

To summarise, the challenges facing us are:

- A wide range of versions of Perl are in use
 - We have a large shared legacy codebase on CPAN, of varying quality, utility, and usage
 - We're missing features that developers expect / want
 - But a lot of people don't even know about / use some of the recent features
 - A reputation for dependability, but also stagnation
 - We want to change these things, but must provide a path for both people and code to come along with us

Sawyer, Rik, Neil

Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About