Front page | perl.perl5.porters |
Postings from June 2020
Re: Announcing Perl 7
Thread Previous
|
Thread Next
From:
Kent Fredric
Date:
June 29, 2020 20:54
Subject:
Re: Announcing Perl 7
Message ID:
CAATnKFDhbqjTRTXtxVigEZhoC3=Vn5zuNLjY5UOFopNtGZbKjg@mail.gmail.com
> Sure, you could tell me that some company's internal code might have their own installation systems. Fine. They can either update their installation software to emulate what the new tooling does or they can simply not upgrade Perl. I would bet that most shops actually use Perl's tooling, in which case they can just upgrade their Perl version and re-install.
Please try to see this problem outside the domain of "web development
is the only place perl gets used".
Because you just basically hit the same problem domain as "linux
vendors" (because vendor code doesn't use CPAN.pm or anything remotely
like that, and maintains a much firmer grip on what perl code can and
can't do inside their build chain). I hope you don't mind that linux
vendors may see this problem and not only not update perl, but also
not necessarily be overly keen on exposing their users to perl7 ( and
if they do, it will likely be in the form of dual-installation[1]
along-side perl5, where all the "serious business" continues to use
perl5 for system related tasks )
And linux vendors very much have to simply cope with 2 realities:
- Lots of perl code is in their workflow, which is NOT on CPAN,
because it's part of various opensource build chains. ( And this
oversight has in the past, broken autotools/friends of autotools with
simply "unescaped {" handling, yes, despite the fact there were
warnings for many years, because this very critical tool hadn't seen a
lot of upstream activity )
- Lots of users, who likely have their own little perl scripts for
various system tasks, who don't even participate in the general perl
ecosystem in a way you might ever see, and all these little perl
scripts are prone to become broken. ( Some of them may even just
inherit a system with such stuff, and have zero knowledge of how it
works, let alone, how to fix it when it breaks )
Yes, all breakages and feature deprecations are subject to tripping
into this problem.
So the net result, whatever p5p does, the more that gets broken,
regardless *how* they break it, the predictable consequence is the
roll-out for linux vendors will be slower. And the slowness is
amplified as a function of how pervasive it already is.
So when you're trying to get brand new users into perl7, you'll really
have to make sure you continue to paper over the "what, why doesn't my
code work? Oh, so why is my system perl so ancient?" situation with
perl-brew and friends.
Is that a net benefit? I doubt it.
In short, I doubt the tooling changes will help vendors, even though
I'm yet to see how it is proposed to work exactly.
[1] And dual-installation is really not easy, especially if you even
anticipate dual-availability of all the supported CPAN modules on
*all* perl implementations on the target platform, because due to ABI
and XS constraints, one must compile each CPAN module independently on
each desired target perl implementation. If this was easy, we'd
already be supporting cperl and stableperl as well, but we aren't,
because the work is too much, and the amount of able bodies to make it
happen is too low, and to add to that, it grossly complicates the work
of the install chain, sometimes expressing that complexity as
user-facing problems and confusion. If my hand is forced on this
matter, perl7 will likely not be the only new target that gets some
love.
--
Kent
KENTNL - https://metacpan.org/author/KENTNL
Thread Previous
|
Thread Next