Front page | perl.perl5.porters |
Postings from June 2020
Re: Announcing Perl 7
Thread Previous
|
Thread Next
From:
David Mertens
Date:
June 26, 2020 13:45
Subject:
Re: Announcing Perl 7
Message ID:
CA+4ieYXdfP03cC4hwN16VeHPLXy89g7fU02xG6JqJ0M31dYN7Q@mail.gmail.com
Yves' comments have significantly clarified something for me, which is that
CPAN authors will explicitly specify their Perl version whether we use Dave
Mitchell's idea (users must explicitly "use v7") or Sawyer's idea (user's
get the latest *if they do not use a specific version*). The difference is
how Perl parses a script/module that *does not* specify a version. Under
Dave they get the oldest; under Sawyer they get the newest. CPAN authors
seeking stability will always declare the version of Perl they want. Thus
the boilerplate for any wise CPAN author is still nonzero, but still really
quite small.
This suggests that the meaning of "use v5.20" should perhaps be slightly
revised with the shift to Perl 7. Moving forward we should change the
meaning of this statement so that it allows the feature set that was
available for that version and *disallows* feature sets turned on with new
major version numbers. Thus if I say "use v7.2" in a CPAN module and I
upgrade to Perl 8, my old code will get the feature set from v7.2
As for XS code, I guess a similar approach would need to be taken: you
would have the #define your Perl major and minor version numbers before
#include "perl.h" or something like that. Again, this would require CPAN
authors to dust off their code and add such preprocessor declarations to
their XS codebases, just like they'll need to do for their Perl codebases.
Dave said: "In 5 years or whatever, it will also save our bacon when perl8
is released; suddenly all that source code with 'use v7;' at the top will
continue to work on the perl8 interpreter running in perl7 mode. Rather
than suddenly all breaking." I guess my point is that in reality, this
won't happen because all competent CPAN authors will state use v7 at the
top of their modules anyway. All we're really doing here is smoothing the
onboarding path for developers new to Perl.
On Fri, Jun 26, 2020 at 8:49 AM demerphq <demerphq@gmail.com> wrote:
> On Fri, 26 Jun 2020 at 09:44, Eric Wong <p5p@yhbt.net> wrote:
> >
> > Karl Williamson <public@khwilliamson.com> wrote:
> > > I don't understand many of the objections. No one is going to force
> people
> > > to move off 5.32, and we are promising a 5-10 year support window. I
> think
> > > that is ample.
> >
> > 5-10 years is not that long a time, considering many scripts
> > have been running unchanged since the 90s or early 2000s.
> >
> > While I'm happy to see my favorite language learning new tricks;
> > I strongly agree with everything Dave Mitchell said, especially
> > about "use v7".
>
> I believe the crunch here is that we want to switch from one model of
> development to another. The old model prioritizes keeping old code
> running exactly as it used to run. There is merit in that policy. But
> there are other workable policies, like some languages basically make
> it clear that the language will change and evolve over time and people
> using it will have to keep up if they want to use the latest release,
> some of the more popular languages around follow this model, so
> clearly there is merit in them as well.
>
> Sawyer has made the argument that our current model prioritizes the
> wrong party; that it prioritizes the users who do not want to make
> perl better, who do not care about perl as a community, but who expect
> the community to care about them - after all the only users who are
> affected are those expect to be able to run old perl code but also
> upgrade to use the latest version of the interpreter. Any user who
> wants to keep their software 100% stable can build the older version
> of perl. He believes that the other policy leads to a more forward
> looking "grow the community" behavior, where old code/language-rules
> which is of little use but for a small minority of our users takes
> precedence over introducing new features that would make the language
> more attractive to a broader audience of devs, and make Perl more
> suitable for solving a wider range of problems.
>
> To achieve this change requiring new code to include "use v7" is a
> non-starter. It HAS to be the other way round or the culture wont
> change. Everybody will continue to expect that their code without the
> 'use v7' marker will continue to work as expected, and they will think
> that the contract with the perl community remains unchanged. But
> Sawyer wants to change the contract *entirely* and requiring an
> assertive trigger in the code fatally undermines that intent. He wants
> "if you dont tell me what version to run as I will assume you want the
> latest feature set always" for a good reason, so that we can tell
> people when their code is going to break when we stop supporting
> things, and for users who dont help us with that have to own the
> breakage. I think this is a lot more reasonable than people are making
> out in the discussion so far.
>
> FWIW, I think that what we are doing now isn't working, Perl is dying
> out. Sawyer has convinced me it is dying because we have roped
> ourselves to dead code and we prioritize the wrong user groups. So I
> feel that broad brush he is right and we should go ahead with his
> plan. We elected him *exactly* to make these kinds of decisions in the
> best interest of the community, of which I feel certain he is trying
> to do.
>
> I have to admit I keep wondering if we could use new file extensions
> to reduce some of the friction in this process, but I can never figure
> out a solution that is really better overall than what Sawyer is
> proposing.
>
> Yves
>
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." -- Brian Kernighan
Thread Previous
|
Thread Next