Perl and Future

In the meantime I have heard and read a lot about the future of Perl. There are arguments about Perl 5 or Perl 6, there are distribution wishes, and there are many questions.

First of all there are different points of contention about Perl 5 and Perl 6:

1. Perl 6 takes much too long to start.
2. Perl 6 is incompatible with Perl 5
3. Perl 6 too complicated

It is actually very easy to answer this question as of July 2019:

1. Perl6 takes too long to start:

Starting Perl 6 on my Macbook Pro takes 0.36s - starting Perl 5 (without strict, without warnings, ...) takes 0.02s, starting Perl 5 + Moose takes 0.34s. So for the execution of 'Modern Perl' programs there is actually a tie.

In the context "I just want to run one of my transformers on the command line." - in this context the tinkering of the one-liner is to be seen rather in the minute range and if a set known to me from sysadmin environments is to be processed, the I/O alone is in the range of 2-3 minutes.

So this is a smoke grenade.

1. Perl 6 is incompatible with Perl 5:

Wow - a quick look at https://metacpan.org/pod/Perl4::CoreLibs shows that even the Perl 5 community has learned late but that a major version bump doesn't happen for nothing.

If you take a look at various changelogs around 1995, you will find comments like "If you never used Perl 4, imagine Perl 5 without objects, without 'my' variables (only dynamically scoped 'local' variables), without function prototypes, with function calls that needs to be prefixed with '&', etc.".

The one or other paradigm, which was still in vogue in 1995, is now considered obsolete.

1. Perl 6 is too complicated:

Too complicated for what? To simply continue programming in the way that Perl 5 already considers obsolete and undesirable in case of doubt? Yes, it's very complicated - and that's a good thing. In an age in which we demand of programs the attributes reliability, stability, accountability, determinism, safety and security, it is perfectly okay to expect the programmer to clearly formulate what the source of a processing is - and not to keep the schema from 1983 until eternity. In such a case the criticism of poorly maintainable Perl code would be completely correct.

No, Perl 6 consistently implements Modern Perl (in fact, Perl 6 was there before Modern Perl was written) and prevents the most common errors from the highest number of Perl users: the system administrators. These are not sophisticated programmers who know the difference between $. and $? in their sleep - nobody should, because since a command line can be 131072 (2^17) characters or longer in the shell, since utf-8 is read and written in the terminal, cryptic short forms of variables are harmful, because they reduce maintainability and remove at least 4 of the above-mentioned attributes of programs.

I see there rather regulars slogans and eternal yesterday defending their benefices.

Then I often hear and read that Perl is used far too rarely. Well, on the one hand that's only half the truth - on the other hand it's becoming more and more the truth due to fights in the community.

The current status is: Perl (5) belongs to the POSIX standard. However, the world of packaging and orchestrating operating system distributions has evolved and Perl (5) stopped where it was in 1995. It has been known since at least the turn of the millennium that during the configure stage, no parameters are read from files to determine compile behavior. It is also extremely unseemly to run self-created test programs and parse their output.

This causes many distributions - POSIX back and forth - to throw Perl 5 out of the base system.

If the Perl community wants the Perl to remain part of POSIX, it should find a POSIX-compliant answer to the question of configure, build & install, not a "Perlish". There are still countless system people (admins, operators, managers, ...) who like to use Perl. But Python is dirty enough now and Ruby is catching up too. And as painful as that may seem - in terms of "satisfying packagers" Python is far ahead of Perl.

But the Perl community must finally realize that Perl 5 has been discontinued by the world. There will certainly be a decade or more of need for support for existing solutions - but it is clearly legacy.

"Would you tell me, please, which way I ought to go from here?", Alice asked. "That depends a good deal on where you want to get to." the cat replied.

For my part, I would recommend two acute steps:

The Perl Foundation should not be an executive organ for individuals, but a democratically or hierarchically organized association of all contributors to Perl.

The Perl Foundation should then actively invite you to do so. And not by nose factor, but in general. Everyone who has a commit bit on Perl {5,6} or regularly maintains modules must at least have the opportunity to express himself and this may also be demanded by regular circulars.

The decision whether Perl 6 is a Perl and thus at least has the possibility to succeed the discontinued Perl 5 must have been made before the end of the year.