develooper Front page | perl.perl5.porters | Postings from August 2020

Re: Q: what the hell is going on? // A: ...

Thread Previous | Thread Next
From:
Paul "LeoNerd" Evans
Date:
August 6, 2020 13:38
Subject:
Re: Q: what the hell is going on? // A: ...
Message ID:
20200806143853.0470dbac@shy.leonerd.org.uk
On Thu, 06 Aug 2020 08:49:48 +0200
Tomasz Konojacki <me@xenu.pl> wrote:

> On Wed, 05 Aug 2020 23:35:59 -0500
> John Lightsey <john@nixnuts.net> wrote:
> 
> > Why would a hard fork of Perl 5 be preferable to Perl 5 and Perl 7
> > being maintained under the same umbrella by the same people?
> > 
> > Sawyer's talk stated that Perl 5 will be maintained without any
> > breaking changes for users that don't want new features or don't
> > feel ready to upgrade. Perl 5 will be more stable than it currently
> > is, not less.
> > 
> > What would a fork of Perl 5 aim to accomplish that isn't already
> > part of the plan to maintain Perl 5 while Perl 7 moves forward?
> > 
> > I'm not trying to be facetious... I see the Perl 5 long term support
> > aspect of the plan as a significant improvement to the status quo.
> > It should make changes to core Perl less of a risk for anyone
> > tending legacy codebases.  
> 
> It's a false dichotomy that all users want either legacy
> maintenance-mode Perl that never changes or total breakage without any
> warning. As I said in my previous post, there's an obvious third way.

Indeed.

My current employer[1], Deriv (formerly Binary), are keen to try out
such new features as FINALLY blocks or in-core try/catch syntax, but
have no plans to do a full version bump up to a 7 if that's going to
require any amount of code change across the entire codebase.

Were there to exist a 5.x that had these new features via the
tried-and-tested

  use v5.34;
  use feature qw( finally try_catch match_case et.al. );

mechanism that we've come to know and love, then they'd be quite happy
to try that out. But a wholesale bump to a "Perl 7" is not viable at
this point.

To be quite clear: such a thing as described above is 100% technically
possible, because it's exactly how Perl has worked the past decade or
so at least. If it turns out not to happen any more it will be because
of a social or political desire not to enable this scenario, not due to
any technical impossibility inherent in it.


[1]: Well, main source of contracting work; not strictly employer as
     such.

-- 
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk      |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/

Thread Previous | 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