Mailing List Archive

Q: what the hell is going on? // A: ...
Fellow list members,

I have gotten a lot of messages in the form "what the hell is going on?" and
it's one of those phrases that people use to mean a lot of different things,
and the way its delivered can bring a lot of different expectations to the
forefront. I think it's a really good question for perl5-porters to have
answered. If we're going to have a lot of disagreement, I want to make sure we
all know what we're disagreeing about!

I am trying very hard not to just swoop in at the tail end and throw another
opinion on the fire.¹ I have send a draft of this email to Sawyer and the Perl
Steering Committee to make sure I'm not standing apart from the rest of that
group but saying I can speak for them. That means that I am trying to
elaborate the "what the hell is going on" from the perspective of the PSC, but
I'm going to be pretty liberal about throwing in my personal perspective here.

Okay, here we go.

## ONE: TO BREAK OR NOT TO BREAK

The big idea actually being debated is, I think, about this paragraph in
perlpolicy:

> Requiring end-user programmers to change just a few language constructs,
> even language constructs which no well-educated developer would ever
> intentionally use is tantamount to saying "you should not upgrade to a
> new release of Perl unless you have 100% test coverage and can do a full
> manual audit of your codebase." If we were to have tools capable of
> reliably upgrading Perl source code from one version of Perl to another,
> this concern could be significantly mitigated.

This paragraph and ones like it form a policy that each new release of Perl may
add, but may almost never take away, behaviors. It also enshrines certain bugs
as canon. Mark Jason Dominus once wrote in parody, "Sure, it would be nice if
2+2 had been made to evaluate to 4 and not 5, but the ship has sailed on that
front." We're not there, but sometimes it feels like it. Every mistake made
before and made now walls perl into a smaller possible set of futures, with
very little recourse to break free.

The central Perl 7 question is not about version numbering, but rather about
backward compatibility guarantees. (There is another key question we need to
grapple with, in the current turmoil, and I'll come back to it. It is the
question of governance -- but that is *also* a question of perlpolicy.)

Sawyer's position is that Perl 5 is too constrained by backward compatibility
to grow significantly in utility or rate of use, at this point. There are a
few possible responses to that, including at least:

* I agree, let's figure out which constraints can, like chains, be shrugged
off so we can move ahead.

* I agree with this premise. Therefore, we should let Perl continue along
its current course, becoming ever more stable as it is used by an
ever-diminishing audience until it is given its rightful place in the Hall
of the Honored Dead.

* I reject this premise. There is a lot of room for forward motion without
breaking changes, if we would just stop trying to change the rules and move
forward.

I think there is merit to all of these positions.

Maybe there are kinds of backward compatibility that can be shrugged off
without disrupting the vast majority of Perl users, while making the language
easier to use and (very importantly) easy to *continue* to improve. This is
obviously the core hope of the Perl 7 plan.

Maybe even the best-chosen set of improvements will be terrific for a small
audience of Perl users, who will be able to avoid or easily adapt to
disruption and then gain ground from the changes -- but the great majority of
the changes will be painful, Perl use will rapidly fall off, and we won't win
any new users.

Maybe we can keep on the current course, finding ever-smaller niches in which
to fit new syntax and features, making life better for users of cutting-edge
Perl, and focusing on breaking compatibility is a symptom of fatigue, not
technical fact.

**The first thing people need to decide is probably what they think on this
question.** Here's what I think: there is room for forward motion without
breaking changes, but it's painstaking and tedious. It gets worse over time.
We aren't picking up new core developers for a bunch of reasons, but one is
"it's just too much of a slog to -do- anything." So I am in favor of making
selective breakages in order to make the language better and the implementation
more workable. I think this is the core of the Perl 7 plan, and the big
question is "what are those selective breakages."

## TWO: HOW SHALL I BREAK THEE?

A lot of people disagree with the premises that lead to "okay, let's break some
backcompat," and that needs one kind of discussion. Other people agree with
the premises and conclusion, but then don't agree on the specifics of what is
"safe to break."

I think it's important to just say very clearly: There is not yet a consensus
here, seemingly among any two people. There is not a cabal of people saying
"let's all break these five things we agree on, quick, before anybody can stop
us." I think sometimes it smells that way, but I have been in the discussions
about what we can and should change, and why, and there is no unified front.

The big agreement is, if anything, "Changing the version numbering to make it
clear when to expect breaking changes is reasonable."

There are a lot of specific changes being discussed. Everyone on the PSC seems
to agree on Perl 7.0.0 existing at some point in the next twelve months.
Beyond that, it's up in the air. The next most common discussion is "and we
change the set of features enabled by default."

There is also a lot of discussion about how to test this, what might break, and
so on. I know that not everybody will agree on whether there can ever be
enough testing, but the impact on existing code is a big question to be
answered. Nobody is arguing that will attract a new set of users and
developers by first alienating all the existing ones. The question is, can we
reduce the impact to only those people who are very unlikely to be affected by
the change anyway? (Answer: I don't have an answer yet.)

So, what *is* the specific plan? The plan is to come up with a plan. I have
heard suggestions that I like and suggestions that I don't like. I will hold
off on holding forth, just now, on what I like best. Instead, I want to talk
about how a plan gets come up with.

## THREE: WHY WERE THE FORMER DAYS BETTER THAN THESE?

Once upon a time, Larry presided over p5p and made decisions about what the
language would do, and this was mostly great because Larry was great, and even
when it wasn't great, we got an answer and we knew it was final.

Then Larry went and worked on another project and we got a string of other
project managers who also made decisions and whether or not this was great is
something to be debated by programming language historians someday.²

The decisions of those project managers was also final, but it rarely seemed
like it led to major strife, for a bunch of reasons. One of these was that
changes got workshopped off the list before being presented. When posted, many
key contributors had already had an argument elsewhere and could now
immediately say, "Yes, I can get behind this." This was not how all changes
worked, and I don't think it's even how *most* worked, but it was extremely
useful for contentious changes.

There was sometimes discussion of how we (where "we" was "the committers" or
"the members of fiveperl") might vote on matters, but I don't think ever took a
vote. (I may be mistaken.) Instead, the project manager managed by the
consent of the managed, established by pre-vetting some ideas and deeply
engaging with others publicly, and often doing both.

This process happened for "let's do Perl 7", but I think that somewhere along
the way, it fell apart. It seemed like consensus had been reached, but it had
not, and when an announcement was made, the expected "Yes, I can get behind
this"es did not all materialize. This meant that there was confusion in the
public discussion, obvious dissent among ranks that were usually closed, and
having a public discussion was going to be very, very difficult without first
establishing some consensus among a core group.

## FOUR: FIVEPERL AND THE PERL STEERING COMMITTEE

Lots of the pre-gathering of consensus back in the day happened on a private
mailing list called fiveperl. The membership was mostly the committers to
perl5.git, but not exactly. For example, as we added committers whose were
really meant only to make releases, they didn't get added to fiveperl. Also,
editing the membership of fiveperl meant dealing with humans who would have to
manually update configuration, which they always did, but it wasn't trivial, so
other committers never got added because it was a pain. The system wasn't
perfect.

Because fiveperl's membership became less reflective of reality, it wasn't how
discussion about the future of Perl happened. As I said above, what happened
instead turned out to be kind of a mess. In light of that mess, there was a
realization that this really needed to be fixed: we needed to establish a group
that served this function of discussion of what's going on without an unbounded
number of voices.

I believe that one of the most important things about fiveperl is that it was
not a decision-making body. It was a cabinet chamber in which the project
manager could speak privately with people who could say what they thought
without worrying too much about how their words would be construed by the whole
body of people interested in Perl. Someone could tell me, "Rik, you are just
tired, this is a bad idea, go to sleep and re-read your post in the
morning" and it would be fine, because it was a private conversation.

We're now grapping with a question of governance: Sawyer said, "Here's what
is going to happen" and a bunch of people said, "Can he even *do* that?" I
believe the answer is "yes," but I agree that it's not entirely clear. Or,
more specifically: if Sawyer governs the project through the consent of the
governed, how are the governed represented? That means:

1. Who are the representatives?
2. How are they empowered to act?

This question is not settled. There now exists "the Perl Steering Committee"
and it has no definite charter or constitution. (There's a page on the wiki³
but it's thrown together.)

Who is going to settle this? To my mind, it's something like the active
committers to the project. This needs clearing up because, for example, does
this include Stevan Little, who has a commit bit because he made a release
once?

And what does it mean to settle this? Part of it is, "We need the charter to
written, sufficient, and something that is not being argued about."

Here's what I can tell you so far:

* We're having irregularly-scheduled teleconferences to talk about what we
can agree on

* The primary function of the PSC (which I imagine as fiveperl v2) is to
provide advice and feedback on ideas to help refine them and form consensus
before they're put up for general discussion

* Almost certainly the only decision that it will be empowered to make will
be the removal of the project manager from office; in all other cases, the
final decision is with the project manager, who has a strong incentive to
see that consensus is established.

You should not expect to see a stream of unjustified dictates issuing forth
from some secret body on high. You should expect to see perl5-porters
operating as it generally did: with proposals coming to the list, getting
discussion, and then being thumbed up or down by the project manager. This is
what has been happening for years, already. Some proposals were already
discussed by the project manager and some were not. If you eliminated any
named mailing list for doing this, it would still happen. The PSC is a means
to say that there is a default group for such discussions. If you were
wondering, its initial membership was formed from "the people who came to or
were invited to the Perl Core Summit" over the last few years.

Finally, I want to express my very strong personal feeling that these kind of
preliminary discussions can't be effective if they are completely recorded.
The addition of an audience is a hindrance to free and open communication among
trusted peers. This is not a seizure of power if the body in question has no
decision-making authority that is not already vested in the project manager.

FIVE: RJBS IS FINALLY WRAPPING UP

To my mind what needs to happen is this:

1. We need to firm up the "here is what the PSC is and is not" document,
post it, and agree that it's done. Either that leads to people rejecting
the validity of future decisions or not, but we can't live in a constant
state of constitutional crisis.

2. We need to begin producing a clear set of intended changes, like "this is
the set of default features we want to test for impact on CPAN", discuss
those on perl5-porters, and take action on them. We need specific
avenues we're exploring or planning on, rather than a state of infinite
uncertainty.

Right now #1 and #2 are, in a sense, happening simultaneously. This is
painful, because it feels like we're getting proposed courses of action from a
body with no clear rules for existing and no clear set of powers, where that
set of powers may or may not be infinite and may or may not be legitimately
claimed. That question needs to be put to rest.

I don't think we can usefully discuss specific plans while we're still
concerned about the authority from which decisions flow, and I think we're
close to presenting an answer to how that works, which each of us on
perl5-porters (and beyond) will need to individually accept or reject as valid.
Until that happens, I just hope for a little period of calm and good faith.

--
rjbs

[1] MADISON: I've been fighting for Perl 5 alone, where have you been?
RJBS : … France.

[2] The ACM's History of Programming Languages conference, held only fifteen
years or so, was meant to happen this year but was postponed. Perhaps Perl
5 can make it into the next conference's agenda.

[3] https://github.com/Perl/perl5/wiki/Perl-Steering-Committee
Re: Q: what the hell is going on? // A: ... [ In reply to ]
Please make sure that breaking changes are controlled by pragmata so that
the integrity of CPAN can be preserved.

On Wed, Aug 5, 2020 at 9:46 PM Ricardo Signes <perl.p5p@rjbs.manxome.org>
wrote:

> Fellow list members,
>
> I have gotten a lot of messages in the form "what the hell is going on?"
> and
> it's one of those phrases that people use to mean a lot of different
> things,
> and the way its delivered can bring a lot of different expectations to the
> forefront. I think it's a really good question for perl5-porters to have
> answered. If we're going to have a lot of disagreement, I want to make
> sure we
> all know what we're disagreeing about!
>
> I am trying very hard not to just swoop in at the tail end and throw
> another
> opinion on the fire.¹ I have send a draft of this email to Sawyer and the
> Perl
> Steering Committee to make sure I'm not standing apart from the rest of
> that
> group but saying I can speak for them. That means that I am trying to
> elaborate the "what the hell is going on" from the perspective of the PSC,
> but
> I'm going to be pretty liberal about throwing in my personal perspective
> here.
>
> Okay, here we go.
>
> ## ONE: TO BREAK OR NOT TO BREAK
>
> The big idea actually being debated is, I think, about this paragraph in
> perlpolicy:
>
> > Requiring end-user programmers to change just a few language constructs,
> > even language constructs which no well-educated developer would ever
> > intentionally use is tantamount to saying "you should not upgrade to a
> > new release of Perl unless you have 100% test coverage and can do a full
> > manual audit of your codebase." If we were to have tools capable of
> > reliably upgrading Perl source code from one version of Perl to another,
> > this concern could be significantly mitigated.
>
> This paragraph and ones like it form a policy that each new release of
> Perl may
> add, but may almost never take away, behaviors. It also enshrines certain
> bugs
> as canon. Mark Jason Dominus once wrote in parody, "Sure, it would be
> nice if
> 2+2 had been made to evaluate to 4 and not 5, but the ship has sailed on
> that
> front." We're not there, but sometimes it feels like it. Every mistake
> made
> before and made now walls perl into a smaller possible set of futures, with
> very little recourse to break free.
>
> The central Perl 7 question is not about version numbering, but rather
> about
> backward compatibility guarantees. (There is another key question we need
> to
> grapple with, in the current turmoil, and I'll come back to it. It is the
> question of governance -- but that is *also* a question of perlpolicy.)
>
> Sawyer's position is that Perl 5 is too constrained by backward
> compatibility
> to grow significantly in utility or rate of use, at this point. There are
> a
> few possible responses to that, including at least:
>
> * I agree, let's figure out which constraints can, like chains, be
> shrugged
> off so we can move ahead.
>
> * I agree with this premise. Therefore, we should let Perl continue
> along
> its current course, becoming ever more stable as it is used by an
> ever-diminishing audience until it is given its rightful place in the
> Hall
> of the Honored Dead.
>
> * I reject this premise. There is a lot of room for forward motion
> without
> breaking changes, if we would just stop trying to change the rules and
> move
> forward.
>
> I think there is merit to all of these positions.
>
> Maybe there are kinds of backward compatibility that can be shrugged off
> without disrupting the vast majority of Perl users, while making the
> language
> easier to use and (very importantly) easy to *continue* to improve. This
> is
> obviously the core hope of the Perl 7 plan.
>
> Maybe even the best-chosen set of improvements will be terrific for a small
> audience of Perl users, who will be able to avoid or easily adapt to
> disruption and then gain ground from the changes -- but the great majority
> of
> the changes will be painful, Perl use will rapidly fall off, and we won't
> win
> any new users.
>
> Maybe we can keep on the current course, finding ever-smaller niches in
> which
> to fit new syntax and features, making life better for users of
> cutting-edge
> Perl, and focusing on breaking compatibility is a symptom of fatigue, not
> technical fact.
>
> **The first thing people need to decide is probably what they think on this
> question.** Here's what I think: there is room for forward motion without
> breaking changes, but it's painstaking and tedious. It gets worse over
> time.
> We aren't picking up new core developers for a bunch of reasons, but one is
> "it's just too much of a slog to -do- anything." So I am in favor of
> making
> selective breakages in order to make the language better and the
> implementation
> more workable. I think this is the core of the Perl 7 plan, and the big
> question is "what are those selective breakages."
>
> ## TWO: HOW SHALL I BREAK THEE?
>
> A lot of people disagree with the premises that lead to "okay, let's break
> some
> backcompat," and that needs one kind of discussion. Other people agree
> with
> the premises and conclusion, but then don't agree on the specifics of what
> is
> "safe to break."
>
> I think it's important to just say very clearly: There is not yet a
> consensus
> here, seemingly among any two people. There is not a cabal of people
> saying
> "let's all break these five things we agree on, quick, before anybody can
> stop
> us." I think sometimes it smells that way, but I have been in the
> discussions
> about what we can and should change, and why, and there is no unified
> front.
>
> The big agreement is, if anything, "Changing the version numbering to make
> it
> clear when to expect breaking changes is reasonable."
>
> There are a lot of specific changes being discussed. Everyone on the PSC
> seems
> to agree on Perl 7.0.0 existing at some point in the next twelve months.
> Beyond that, it's up in the air. The next most common discussion is "and
> we
> change the set of features enabled by default."
>
> There is also a lot of discussion about how to test this, what might
> break, and
> so on. I know that not everybody will agree on whether there can ever be
> enough testing, but the impact on existing code is a big question to be
> answered. Nobody is arguing that will attract a new set of users and
> developers by first alienating all the existing ones. The question is,
> can we
> reduce the impact to only those people who are very unlikely to be
> affected by
> the change anyway? (Answer: I don't have an answer yet.)
>
> So, what *is* the specific plan? The plan is to come up with a plan. I
> have
> heard suggestions that I like and suggestions that I don't like. I will
> hold
> off on holding forth, just now, on what I like best. Instead, I want to
> talk
> about how a plan gets come up with.
>
> ## THREE: WHY WERE THE FORMER DAYS BETTER THAN THESE?
>
> Once upon a time, Larry presided over p5p and made decisions about what the
> language would do, and this was mostly great because Larry was great, and
> even
> when it wasn't great, we got an answer and we knew it was final.
>
> Then Larry went and worked on another project and we got a string of other
> project managers who also made decisions and whether or not this was great
> is
> something to be debated by programming language historians someday.²
>
> The decisions of those project managers was also final, but it rarely
> seemed
> like it led to major strife, for a bunch of reasons. One of these was that
> changes got workshopped off the list before being presented. When posted,
> many
> key contributors had already had an argument elsewhere and could now
> immediately say, "Yes, I can get behind this." This was not how all
> changes
> worked, and I don't think it's even how *most* worked, but it was extremely
> useful for contentious changes.
>
> There was sometimes discussion of how we (where "we" was "the committers"
> or
> "the members of fiveperl") might vote on matters, but I don't think ever
> took a
> vote. (I may be mistaken.) Instead, the project manager managed by the
> consent of the managed, established by pre-vetting some ideas and deeply
> engaging with others publicly, and often doing both.
>
> This process happened for "let's do Perl 7", but I think that somewhere
> along
> the way, it fell apart. It seemed like consensus had been reached, but it
> had
> not, and when an announcement was made, the expected "Yes, I can get behind
> this"es did not all materialize. This meant that there was confusion in
> the
> public discussion, obvious dissent among ranks that were usually closed,
> and
> having a public discussion was going to be very, very difficult without
> first
> establishing some consensus among a core group.
>
> ## FOUR: FIVEPERL AND THE PERL STEERING COMMITTEE
>
> Lots of the pre-gathering of consensus back in the day happened on a
> private
> mailing list called fiveperl. The membership was mostly the committers to
> perl5.git, but not exactly. For example, as we added committers whose were
> really meant only to make releases, they didn't get added to fiveperl.
> Also,
> editing the membership of fiveperl meant dealing with humans who would
> have to
> manually update configuration, which they always did, but it wasn't
> trivial, so
> other committers never got added because it was a pain. The system wasn't
> perfect.
>
> Because fiveperl's membership became less reflective of reality, it wasn't
> how
> discussion about the future of Perl happened. As I said above, what
> happened
> instead turned out to be kind of a mess. In light of that mess, there was
> a
> realization that this really needed to be fixed: we needed to establish a
> group
> that served this function of discussion of what's going on without an
> unbounded
> number of voices.
>
> I believe that one of the most important things about fiveperl is that it
> was
> not a decision-making body. It was a cabinet chamber in which the project
> manager could speak privately with people who could say what they thought
> without worrying too much about how their words would be construed by the
> whole
> body of people interested in Perl. Someone could tell me, "Rik, you are
> just
> tired, this is a bad idea, go to sleep and re-read your post in the
> morning" and it would be fine, because it was a private conversation.
>
> We're now grapping with a question of governance: Sawyer said, "Here's
> what
> is going to happen" and a bunch of people said, "Can he even *do* that?" I
> believe the answer is "yes," but I agree that it's not entirely clear. Or,
> more specifically: if Sawyer governs the project through the consent of the
> governed, how are the governed represented? That means:
>
> 1. Who are the representatives?
> 2. How are they empowered to act?
>
> This question is not settled. There now exists "the Perl Steering
> Committee"
> and it has no definite charter or constitution. (There's a page on the
> wiki³
> but it's thrown together.)
>
> Who is going to settle this? To my mind, it's something like the active
> committers to the project. This needs clearing up because, for example,
> does
> this include Stevan Little, who has a commit bit because he made a release
> once?
>
> And what does it mean to settle this? Part of it is, "We need the charter
> to
> written, sufficient, and something that is not being argued about."
>
> Here's what I can tell you so far:
>
> * We're having irregularly-scheduled teleconferences to talk about what
> we
> can agree on
>
> * The primary function of the PSC (which I imagine as fiveperl v2) is to
> provide advice and feedback on ideas to help refine them and form
> consensus
> before they're put up for general discussion
>
> * Almost certainly the only decision that it will be empowered to make
> will
> be the removal of the project manager from office; in all other cases,
> the
> final decision is with the project manager, who has a strong incentive
> to
> see that consensus is established.
>
> You should not expect to see a stream of unjustified dictates issuing forth
> from some secret body on high. You should expect to see perl5-porters
> operating as it generally did: with proposals coming to the list, getting
> discussion, and then being thumbed up or down by the project manager.
> This is
> what has been happening for years, already. Some proposals were already
> discussed by the project manager and some were not. If you eliminated any
> named mailing list for doing this, it would still happen. The PSC is a
> means
> to say that there is a default group for such discussions. If you were
> wondering, its initial membership was formed from "the people who came to
> or
> were invited to the Perl Core Summit" over the last few years.
>
> Finally, I want to express my very strong personal feeling that these kind
> of
> preliminary discussions can't be effective if they are completely recorded.
> The addition of an audience is a hindrance to free and open communication
> among
> trusted peers. This is not a seizure of power if the body in question has
> no
> decision-making authority that is not already vested in the project
> manager.
>
> FIVE: RJBS IS FINALLY WRAPPING UP
>
> To my mind what needs to happen is this:
>
> 1. We need to firm up the "here is what the PSC is and is not" document,
> post it, and agree that it's done. Either that leads to people
> rejecting
> the validity of future decisions or not, but we can't live in a
> constant
> state of constitutional crisis.
>
> 2. We need to begin producing a clear set of intended changes, like
> "this is
> the set of default features we want to test for impact on CPAN",
> discuss
> those on perl5-porters, and take action on them. We need specific
> avenues we're exploring or planning on, rather than a state of
> infinite
> uncertainty.
>
> Right now #1 and #2 are, in a sense, happening simultaneously. This is
> painful, because it feels like we're getting proposed courses of action
> from a
> body with no clear rules for existing and no clear set of powers, where
> that
> set of powers may or may not be infinite and may or may not be legitimately
> claimed. That question needs to be put to rest.
>
> I don't think we can usefully discuss specific plans while we're still
> concerned about the authority from which decisions flow, and I think we're
> close to presenting an answer to how that works, which each of us on
> perl5-porters (and beyond) will need to individually accept or reject as
> valid.
> Until that happens, I just hope for a little period of calm and good faith.
>
> --
> rjbs
>
> [1] MADISON: I've been fighting for Perl 5 alone, where have you been?
> RJBS : … France.
>
> [2] The ACM's History of Programming Languages conference, held only
> fifteen
> years or so, was meant to happen this year but was postponed. Perhaps
> Perl
> 5 can make it into the next conference's agenda.
>
> [3] https://github.com/Perl/perl5/wiki/Perl-Steering-Committee
>


--
Thanks,

Phil <https://metacpan.org/author/PRBRENAN>

Philip R Brenan <https://metacpan.org/author/PRBRENAN>
Re: Q: what the hell is going on? // A: ... [ In reply to ]
On Wed, 05 Aug 2020 22:46:31 +0200, Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:

> Fellow list members,

Thanks for taking the time. :)

If i understand it right, the intent is:

- there's a private preprint area where things can be shot down before going public
- anything that makes it is thrown into p5p so everyone can yell at it
- the pumpking listens to the yelling for a few weeks to find points of merit
- they then make the final call and justification of which way to go

Does that sound about right?

If yeah, then i think that makes most everyone satisfied, and i agree no recording or even notes would be necessary or helpful.

--
With regards,
Christian Walde

(Note: While it's possibly academic, I still consider the idea of a video call to inherently preclude people with certain disabilities for consideration. I do not have an alternative and i realize a text-only environment has the same effect with other disabilities ... but i want people to make this trade-off while being aware of this being what they're doing. */soapbox*)
Re: Q: what the hell is going on? // A: ... [ In reply to ]
* Christian Walde <walde.christian@gmail.com> [2020-08-05T18:52:56]
> Thanks for taking the time. :)
>
> If i understand it right, the intent is:
>
> - there's a private preprint area where things can be shot down before going public
> - anything that makes it is thrown into p5p so everyone can yell at it
> - the pumpking listens to the yelling for a few weeks to find points of merit
> - they then make the final call and justification of which way to go

Largely, yes, I believe so. But:

* let's not yell at things ;-)

* let's say "a while" instead of "a few weeks" -- different ideas need
different amounts of percolation

--
rjbs
Re: Q: what the hell is going on? // A: ... [ In reply to ]
On Thu, 06 Aug 2020 00:57:55 +0200, Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:

> * Christian Walde <walde.christian@gmail.com> [2020-08-05T18:52:56]
>> Thanks for taking the time. :)
>>
>> If i understand it right, the intent is:
>>
>> - there's a private preprint area where things can be shot down before going public
>> - anything that makes it is thrown into p5p so everyone can yell at it
>> - the pumpking listens to the yelling for a few weeks to find points of merit
>> - they then make the final call and justification of which way to go
>
> Largely, yes, I believe so. But:
>
> * let's not yell at things ;-)
>
> * let's say "a while" instead of "a few weeks" -- different ideas need
> different amounts of percolation

I was writing somewhat tongue-in-cheek. :D

--
With regards,
Christian Walde
Re: Q: what the hell is going on? // A: ... [ In reply to ]
On Wed, 5 Aug 2020 16:46:31 -0400
Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:

> There is not a cabal of people saying
> "let's all break these five things we agree on, quick, before anybody can stop
> us." I think sometimes it smells that way, but I have been in the discussions
> about what we can and should change, and why, and there is no unified front.

This is literally what is happenning right now and I'm saying this as
someone who is firmly in the "we need to modernize Perl ASAP" camp.

Bumping the major version doesn't give us a license to arbitrarily break
user's code. We need deprecation cycles. It seems that Sawyer & co. forgot that
they exist.

There's absolutely no indication in Perl 5.34 that, for example, the code
that has a sub named "say" will stop working in the very next release.
No warnings, no nothing. This is completely unacceptable.

>There are a lot of specific changes being discussed. Everyone on the PSC seems
>to agree on Perl 7.0.0 existing at some point in the next twelve months.
>Beyond that, it's up in the air.

There's no reason why we have to release Perl 7 *now*, other than saving
Sawyer's face and brian's book sales. BTW, AFAIK it's not true that
there's a full consensus among PSC members about this.

In my opinion, the only way forward is to release Perl 5.36 which will
add deprecation warnings for the stuff we want to remove/disable by
default in Perl 7 and then continue making 5.x releases until we are
actually ready to release Perl 7. That will, of course, take a few years.

Releasing Perl 7 in the way that was described in Sawyer's talk will
result in a catastrophe. It will be a PR disaster (it already is), it
will fragment the community and possibly even result in a hard fork of
Perl (BTW, as someone who has contributed 32 commits to Perl in the past
year, I will probably support it, if it happens).

I don't think anyone actually wants that scenario to happen. Let's stop
this madness.
Re: Q: what the hell is going on? // A: ... [ In reply to ]
On Thu, 06 Aug 2020 01:12:35 +0200
Tomasz Konojacki <me@xenu.pl> wrote:

> There's absolutely no indication in Perl 5.34 that, for example, the code
> that has a sub named "say" will stop working in the very next release.
> No warnings, no nothing. This is completely unacceptable.

Oops, s/5.34/5.32/

> In my opinion, the only way forward is to release Perl 5.36 which will
> add deprecation warnings for the stuff we want to remove/disable by
> default in Perl 7 and then continue making 5.x releases until we are
> actually ready to release Perl 7. That will, of course, take a few years.

s/5.36/5.34/;
Re: Q: what the hell is going on? // A: ... [ In reply to ]
On Thu, 2020-08-06 at 01:12 +0200, Tomasz Konojacki wrote:
> On Wed, 5 Aug 2020 16:46:31 -0400
> Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:

> > There are a lot of specific changes being discussed. Everyone on the PSC seems
> > to agree on Perl 7.0.0 existing at some point in the next twelve months.
> > Beyond that, it's up in the air.
>
> There's no reason why we have to release Perl 7 *now*, other than saving
> Sawyer's face and brian's book sales. BTW, AFAIK it's not true that
> there's a full consensus among PSC members about this.
>
> In my opinion, the only way forward is to release Perl 5.36 which will
> add deprecation warnings for the stuff we want to remove/disable by
> default in Perl 7 and then continue making 5.x releases until we are
> actually ready to release Perl 7. That will, of course, take a few years.
>
> Releasing Perl 7 in the way that was described in Sawyer's talk will
> result in a catastrophe. It will be a PR disaster (it already is), it
> will fragment the community and possibly even result in a hard fork of
> Perl (BTW, as someone who has contributed 32 commits to Perl in the past
> year, I will probably support it, if it happens).

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.



J.D.
Re: Q: what the hell is going on? // A: ... [ In reply to ]
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.
Re: Q: what the hell is going on? // A: ... [ In reply to ]
On Thu, Aug 6, 2020 at 8:50 AM 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.
>

This is probably the most important open question of this whole plan.

I suspect this is not what most people prefer to happen (it's certainly a
complication), but they're probably currently not willing to give up their
side of the fork to make it not happen. Unless one party either gives up
(which seems unlikely) or comes up with a compromise that is acceptable to
the other (apparently difficult), it is a likely outcome.

It all rather feels like a Solomon's judgement to me.

Leon
Re: Q: what the hell is going on? // A: ... [ In reply to ]
On 06.08.2020 01:12, Tomasz Konojacki wrote:
> On Wed, 5 Aug 2020 16:46:31 -0400
> Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:
>
>> There is not a cabal of people saying
>> "let's all break these five things we agree on, quick, before anybody can stop
>> us." I think sometimes it smells that way, but I have been in the discussions
>> about what we can and should change, and why, and there is no unified front.
>
> This is literally what is happenning right now and I'm saying this as
> someone who is firmly in the "we need to modernize Perl ASAP" camp.
>
> Bumping the major version doesn't give us a license to arbitrarily break
> user's code. We need deprecation cycles. It seems that Sawyer & co. forgot that
> they exist.
>
> There's absolutely no indication in Perl 5.34 that, for example, the code
> that has a sub named "say" will stop working in the very next release.
> No warnings, no nothing. This is completely unacceptable.
>
>> There are a lot of specific changes being discussed. Everyone on the PSC seems
>> to agree on Perl 7.0.0 existing at some point in the next twelve months.
>> Beyond that, it's up in the air.
>
> There's no reason why we have to release Perl 7 *now*, other than saving
> Sawyer's face and brian's book sales. BTW, AFAIK it's not true that
> there's a full consensus among PSC members about this.
>
> In my opinion, the only way forward is to release Perl 5.36 which will
> add deprecation warnings for the stuff we want to remove/disable by
> default in Perl 7 and then continue making 5.x releases until we are
> actually ready to release Perl 7. That will, of course, take a few years.
>
> Releasing Perl 7 in the way that was described in Sawyer's talk will
> result in a catastrophe. It will be a PR disaster (it already is), it
> will fragment the community and possibly even result in a hard fork of
> Perl (BTW, as someone who has contributed 32 commits to Perl in the past
> year, I will probably support it, if it happens).
>
> I don't think anyone actually wants that scenario to happen. Let's stop
> this madness.
>

If anyone is still willing to listen to my kind of "perl stakeholder" (*), I have to agree
with the above and say that, following what is happening on this list over the last few
weeks, that is exactly the impression I'm having : madness, and heading for a split
(again?) of the perl community.

I don't want to present things in terms of "black or white", but I get the impression that
in the name of "language purity" and "modernity", some people are quite ready to ignore
hundreds of cumulative years of investment in application code and CPAN library modules,
and to take the risk of breaking it all. And anyone who objects is looked at as an old
stuck-in-the-mud dinosaur.

And I cannot stop myself from wondering, if the point is really to make changes to perl to
make it more "modern" and more attractive to young programmers (**), why not switch to
Perl6/Raku then ?
(I have not done this myself yet, but from my perusing of its documentation, that is a
language that seems to be and do just what I've read here about the rationale for this
breaking change; and Raku seems to have done what it could, to preserve existing
CPAN-modules usability).

I will finish by stating that I have the greatest respect and gratitude for the people who
have been developing, maintaining and improving perl over the years. My life and business
would not be the same without them. But from the latest discussions on this list, I have
to wonder if some of these admirable people, sometimes, are not living in some "ivory
tower" rather removed from day-to-day reality.

André

(*) Someone who has been using perl for 25+ years as an application development language,
and who currently owns a software company employing 15+ programmers and of which probably
75% of the business rests on an existing perl 5 / CPAN codebase.

(**) something which, in the principle, I totally agree with.
I've also had trouble over the years recruiting new programmers and convincing them that
perl was worth looking at.
Re: Q: what the hell is going on? // A: ... [ In reply to ]
Op 06-08-20 om 06:35 schreef John Lightsey:
> On Thu, 2020-08-06 at 01:12 +0200, Tomasz Konojacki wrote:
>> On Wed, 5 Aug 2020 16:46:31 -0400
>> Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:
>>> There are a lot of specific changes being discussed. Everyone on the PSC seems
>>> to agree on Perl 7.0.0 existing at some point in the next twelve months.
>>> Beyond that, it's up in the air.
>> There's no reason why we have to release Perl 7 *now*, other than saving
>> Sawyer's face and brian's book sales. BTW, AFAIK it's not true that
>> there's a full consensus among PSC members about this.
>>
>> In my opinion, the only way forward is to release Perl 5.36 which will
>> add deprecation warnings for the stuff we want to remove/disable by
>> default in Perl 7 and then continue making 5.x releases until we are
>> actually ready to release Perl 7. That will, of course, take a few years.
>>
>> Releasing Perl 7 in the way that was described in Sawyer's talk will
>> result in a catastrophe. It will be a PR disaster (it already is), it
>> will fragment the community and possibly even result in a hard fork of
>> Perl (BTW, as someone who has contributed 32 commits to Perl in the past
>> year, I will probably support it, if it happens).
> 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?
>

The main argument for not doing this, IIRC, was that we would have to
maintain two CPANs, which would grow increasingly out of sync. And we
would have to port all unmaintained but widely used CPAN modules to Perl
7. Both are undoable if you think about it.


HTH,

M4
Re: Q: what the hell is going on? // A: ... [ In reply to ]
On Thu, 6 Aug 2020 11:09:30 +0200, André Warnier (tomcat/perl)
<aw@ice-sa.com> wrote:

> And I cannot stop myself from wondering, if the point is really to
> make changes to perl to make it more "modern" and more attractive to
> young programmers (**), why not switch to Perl6/Raku then ?

1. Raku is a completely different (and beautiful) language
Learning it is absolutely worthwhile, but it still is a different
language (though the possibilities to express your thoughts in code
is probably even better that perl)

2. Perl is still extremely faster than Raku is some areas, esp if XS is
used. If speed is crucial, you will have to write something in both
and compare for your situation to decide

3. CPAN is "the solution code base" for Perl, and will be. Noone is
trying to make it obsolete or fail.

4. The point is not "just" to make the language more attractive to new
programmers. (if that was the only point to make, Raku could well be
the answer). We - as core developers - are currently hindered in
making changes to the core to fix issues or add features we want to
have (with end users in focus) *without* breaking the world. We now
have to live with years of legacy code of which some has been
written for perl4. As an example, $Foo'Bar'x was perl4 syntax for
$Foo::Bar::x and it is *still* supported. Getting rid of that in a
limited scope will make the parser a lot easier to extend and e.g.
support try/catch. (this may be a false dependency, but used just as
an example). I honestly think that there is less than 0.01% of the
users who would object to dropping support for "'" as package
separator if that would open the road to full-featured exception
handling. *Those* are the changed being discussed.

5. In this process, we (the core team) also modernize the internals to
follow the guidance we always give to new users: use strict and use
warnings will be always on in *internal* code. Note that end-users
or modules will not even notice. The code is just safer and better
tested.

FWIW I have used and still use Perl since 4.018, where I implemented a
Unify database layer ala ora_perl in uni_perl. I currently maintain
Text::CSV_XS and we used that as a canary in the coalmine to see if
anything we discuss would break that (and some other modules high up
in the river). So far, we are just in discussion, and - as rjbs already
said - nothing has been carved in stone. Text::CSV_XS currently
supports perl version 5.6.1 .. 5.33.0 (all of those are tested threaded
and unthreaded before a release is made) and also passes its tests if I
would enable all the restrictions that have been proposed in the
discussion process, so I think that "Everything will break" is
extremely exaggerated and not true at all.

If we do not discuss a road forward, nothing will happen and people
will leave to other languages that *do* allow the features they hope to
find.

For me, Perl is *the* language of choice, as it enables me to express
my thoughts in a language that I like in a format/style that I like.

I use Perl in production code (with a minimum of version 5.14.2 for
different reasons) and I do not want to have that code break. At all.

--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.31 porting perl5 on HP-UX, AIX, and Linux
https://useplaintext.email https://tux.nl http://www.test-smoke.org
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: Q: what the hell is going on? // A: ... [ In reply to ]
On Thu, 6 Aug 2020 11:51:43 +0200
"H.Merijn Brand" <perl5@tux.freedom.nl> wrote:

> 4. The point is not "just" to make the language more attractive to new
> programmers. (if that was the only point to make, Raku could well
> be the answer). We - as core developers - are currently hindered in
> making changes to the core to fix issues or add features we want to
> have (with end users in focus) *without* breaking the world.

I am getting very tired of hearing this as an argument.

As a person who actually *has* added a feature (the `isa` operator),
*is* adding a feature (`FINALLY` blocks), and plans to add many more
(try/catch, dumbmatch, ...) I can categorically state that none of this
has ever got in my way. Not one thing that could be called "supporting
legacy" has ever been in the way of my adding any of these things, and
I don't anticipate any of them being so.

There is a huge long list of things that could be better, which would
make adding these things easier. Such ideas as:

*) There is almost no documentation at all of how to actually add new
features, warnings, keywords, opcodes, syntax, ... I have had to
discover it all from scratch, and lots of asking questions -
mostly to DaveM. We have a very tiny bus-factor about this and
frankly it scares me :(

*) The whole "regen" system is a bit weird.

*) A lot of the core tests are very fragile to breakage by adding new
features. t/op/coreamp.t and the "untagged opcode" warnings that
come from B/Opcode.pm in relation to the "Safe" feature, are two
that come to mind. Fixing those is each a trivial one-word change
but first you have to know and understand them. That takes time.
Again.

> As an example, $Foo'Bar'x was perl4 syntax for
> $Foo::Bar::x and it is *still* supported. Getting rid of that in a
> limited scope will make the parser a lot easier to extend and e.g.
> support try/catch. (this may be a false dependency, but used just
> as an example).

It definitely is a false example. I can again state with absolute
certainty that never once have I had to think about Package'Separators
when adding `isa` or `FINALLY` and I don't expect I will have to when
adding try/catch either.

> I honestly think that there is less than 0.01% of the
> users who would object to dropping support for "'" as package
> separator if that would open the road to full-featured exception
> handling. *Those* are the changed being discussed.

We haven't discussed dropping anything. The only discussions about
"Perl 7" we've ever had have been about what features and pragmata to
enable by default, on the hope of being nicer to new users. Never was
any of that aimed at making our lives as core maintainers easier. It is
totally orthogonal to that.


In summary can we *please* put this whole argument to bed, that "Perl 7
makes it easier for us to maintain core". It doesn't. There are other
things core could do to make that easier but this is not one of them.

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Re: Q: what the hell is going on? // A: ... [ In reply to ]
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/
Re: Q: what the hell is going on? // A: ... [ In reply to ]
On Thu, Aug 6, 2020 at 1:50 AM Tomasz Konojacki <me@xenu.pl> wrote:

> 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.

+1. I believe you have raised this point before. Branislav mentioned
"feature lifecycles" more than once. I and others have raised similar
points. It is a very common and, as you say, obvious way of doing
things that almost every open source project of any size practices in
some form. Yet the most obvious way to balance backward compatibility
and forward movement seems not to have been considered, is not in the
list of "perceived positions" collated by the steering committee,[1]
and was perhaps allowed but not explicitly mentioned in Ricardo's post
that opened this thread.

Changing what features are enabled by default in no way requires one
big bet-the-farm incompatible change on short notice. Consider an
alternate universe in which v5.32 was released along with an
announcement that in v5.36, "use v5.12" or equivalent would be on by
default and in v5.40 would become mandatory. Paul Evans has recently
reminded us of just how much that does.[2] People would have five
years to get ready for the end of support of 5.38.x, including getting
CPAN and the toolchain into a form where a module version can specify
the minimum and maximum Perl versions it supports. Meanwhile, v5.34
could announce a new feature bundle to be enabled in v5.38 and
mandatory in v5.42. Lather, rinse, repeat. And possibly rename 5.40.0
to 7.0.0 and use a new major version whenever a new feature bundle
becomes mandatory.

Maybe five years is too little (though in the example I gave, it
starts with a feature bundle that has already been available for 10
years). The principles of least surprise and fair warning are more
important than any particular feature lifetime. Six months is
definitely too little and forever is plausibly too long. Why those
were considered the only alternatives continues to mystify me.

[1] https://github.com/Perl/perl5/wiki/Perceived-Positions-on-Perl-7
[2] https://groups.google.com/forum/message/raw?msg=perl.perl5.porters/fpx9yNkKgak/7HFpSBk5AgAJ
Re: Q: what the hell is going on? // A: ... [ In reply to ]
On 8/6/20 9:49 AM, Tomasz Konojacki 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.


I think you're creating a straw-man here.


No one, including myself or anyone who worked or supported the plan, had
ever said "total breakage without any warning."


As long as you rephrase my words or the plan we've raised as something
it is not, it cannot be argued properly.
Re: Q: what the hell is going on? // A: ... [ In reply to ]
If there are any breaking changes that are not made optional by pragmata
then we have two classes of Perl citizens some of whom are more equal than
others: those who decide how and when breaking changes will occur and the
hoi polloi who must either accept these changes with no say or move on to
another language. I believe we should be faithful to our creed:

https://en.wikipedia.org/wiki/There%27s_more_than_one_way_to_do_it

by continuing to allow each and every user to individually control the
features of the language they wish to use just as we do now via *use*
statements. By doing so, democratically, we would make Perl more powerful
than any other language out there, even those controlled by benevolent
dictators for life. St Paul tells us that this is possible and I dare to
believe him because if not, we do not deserve to call ourselves programmers
in any language, let alone Perl.


On Thu, Aug 6, 2020 at 5:49 PM Sawyer X <xsawyerx@gmail.com> wrote:

>
> On 8/6/20 9:49 AM, Tomasz Konojacki 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.
>
>
> I think you're creating a straw-man here.
>
>
> No one, including myself or anyone who worked or supported the plan, had
> ever said "total breakage without any warning."
>
>
> As long as you rephrase my words or the plan we've raised as something
> it is not, it cannot be argued properly.
>


--
Thanks,

Phil <https://metacpan.org/author/PRBRENAN>

Philip R Brenan <https://metacpan.org/author/PRBRENAN>
Re: Q: what the hell is going on? // A: ... [ In reply to ]
On 8/6/20 8:15 PM, Philip R Brenan wrote:
> If there are any breaking changes that are not made optional by
> pragmata then we have two classes of Perl citizens some of whom are
> more equal than others: those who decide how and when  breaking
> changes will occur and the hoi polloi who must either accept these
> changes with no say or move on to another language. I believe we
> should be faithful to our creed:
>
> https://en.wikipedia.org/wiki/There%27s_more_than_one_way_to_do_it



At the moment, without any changes, we still have more than one "class
of Perl citizens" in which one takes priority. The question is between
those classes. These two are prominent: 1. The developer who sees
whatever Perl they wrote never changing and 2. the developer who wants
the best[1] Perl out of the box.


The class that prefers no code ever be change once written is currently
the first class of citizens. Their needs take priority to anything - new
users, new features, bug fixes, speed optimizations, everything. It's
true we've removed things, but rarely, and they are an exception.
Reinstating bugs to not hurt existing code that refuses to change is
more common and a much simpler decision in Perl.


Any company that now picks up Perl (as if many would...), all of their
developers (existing and new ones) must learn how to bring Perl to an
acceptable level. They will add strict and warnings. The developers are
already accustomed to function signatures (coming from practically any
other language around) and will want that (if they know it exists) so
will need to turn those on. They will eventually be bitten by bareword
filehandles, by indirect syntax, and more. They will need to learn about
them as they get bitten and learn to avoid them, debug obscure messages,
and perhaps add additional pragmas to disable them - see "bring Perl to
an acceptable level."


That company that is trying to increase the use of Perl and build new
things, as well as all of its developers, are second class citizens. Not
in the dystopia future people are pontificating about, but right now.
They currently matter less to the Perl language. The first class
citizens are first class because they get a free ride with no changes at
the cost of these developers above. In fact, we're signaling to this
company that picking up Perl is not in the interest of the Perl language
developers themselves. The community, in supporting this "balance," is
signaling that Perl is not for anything new - which strongly contradicts
all the conferences, blog posts, and pamphlets we tried pushing forward
over the years. (Although, there are people who wish the language stay
put - no new releases even. I'm going to avoid them for now, since
they're welcome to use an old version of Perl - 5.6 is still available.)


It seems like you're assuming that these developers who request their
code never change are not coming at any expense, but this is simply not
true. Of course, it's a bit silly when this argument is made and the
response is "So we break everything?" as if anyone even suggested moving
to the other extreme. We've done this. It exists. It's called Raku and
it's great. But it isn't Perl. (Arguably, for a reason. :))


Our position used to be "it can be broken and it can require everyone to
continuously work around it till infinity, but code once written is
king."[2] We all understand this argument. Considering this evidently
isn't helping Perl grow (and in fact makes it all the more reason to
just rewrite existing Perl code than continue developing it - not to
mention picking up Perl), that position needs to be challenged. Far
beyond "should we? Nah? Okay," but much more strongly challenged. That's
what we did at Perl Core Summits and that's what this is about.


[1] "Best" is subjective. Here I'm referring to "using the best
practices and patterns that we teach and recommend (like strict and
warnings) and having new capabilities we introduced." In "new
capabilities" I'm thinking more about current_sub (__SUB__), rather than
"say".
Re: Q: what the hell is going on? // A: ... [ In reply to ]
On Thu, 2020-08-06 at 11:39 -0500, Craig A. Berry wrote:
> Changing what features are enabled by default in no way requires one
> big bet-the-farm incompatible change on short notice. Consider an
> alternate universe in which v5.32 was released along with an
> announcement that in v5.36, "use v5.12" or equivalent would be on by
> default and in v5.40 would become mandatory. Paul Evans has recently
> reminded us of just how much that does.[2] People would have five
> years to get ready for the end of support of 5.38.x, including getting
> CPAN and the toolchain into a form where a module version can specify
> the minimum and maximum Perl versions it supports. Meanwhile, v5.34
> could announce a new feature bundle to be enabled in v5.38 and
> mandatory in v5.42. Lather, rinse, repeat. And possibly rename 5.40.0
> to 7.0.0 and use a new major version whenever a new feature bundle
> becomes mandatory.

I don't understand why supporting a stable Perl 5 and releasing a
slightly more fast-moving Perl 7 are mutually exclusive.

I would assume Perl 5 going into a maintenance mode long term support
phase give users the option of adopting Perl 7 on their own timeframe
when they are ready to do so. I would also assume that users sticking
with Perl 5 don't want disruptive changes in Perl 5.

You're saying they'll have no notice with the current plan...and that
switching the behaviors in a minor version release will be less of a
hassle to users than doing so across a major version release.

The approach you favor is definitely more consistent with the current
Perl 5 release practices. Whether the current release practices are
helping the long term outlook for the Perl language seems debatable.

To me, the reasonably broad support for doing something different
(ignoring disagreements over what form that "something" should take)
suggests that there are a lot of people who feel like the long term
future of the Perl language is in doubt.

If you don't agree with that sentiment, then indeed the status quo is
working very well and there's no good reason to change it.

If you do agree with that sentiment, then is a five year transition plan
to Perl 7 honestly going to improve things?

J.D.
Re: Q: what the hell is going on? // A: ... [ In reply to ]
On Thu, Aug 6, 2020 at 12:42 PM Paul "LeoNerd" Evans <leonerd@leonerd.org.uk>
wrote:

> On Thu, 6 Aug 2020 11:51:43 +0200
> "H.Merijn Brand" <perl5@tux.freedom.nl> wrote:
>
> > 4. The point is not "just" to make the language more attractive to new
> > programmers. (if that was the only point to make, Raku could well
> > be the answer). We - as core developers - are currently hindered in
> > making changes to the core to fix issues or add features we want to
> > have (with end users in focus) *without* breaking the world.
>
> I am getting very tired of hearing this as an argument.
>
> As a person who actually *has* added a feature (the `isa` operator),
> *is* adding a feature (`FINALLY` blocks), and plans to add many more
> (try/catch, dumbmatch, ...) I can categorically state that none of this
> has ever got in my way. Not one thing that could be called "supporting
> legacy" has ever been in the way of my adding any of these things, and
> I don't anticipate any of them being so.
>

More specifically, to quote Dave Mitchel's reply to the announcement:

«In fact by far the biggest issue with backwards compatibility in the
interpreter is XS code, especially XS code which relies on stuff outside
the API (or where its not clear whether its API or not). Nothing in the
perl7 proposal (as far as I'm aware) fixes this - it will still be by far
the biggest millstone around our necks in terms of maintaining and
improving the interpreter.»

Leon
Re: Q: what the hell is going on? // A: ... [ In reply to ]
On Thu, Aug 6, 2020 at 4:38 PM John Lightsey <john@nixnuts.net> wrote:
>
> On Thu, 2020-08-06 at 11:39 -0500, Craig A. Berry wrote:
> > Changing what features are enabled by default in no way requires one
> > big bet-the-farm incompatible change on short notice. Consider an
> > alternate universe in which v5.32 was released along with an
> > announcement that in v5.36, "use v5.12" or equivalent would be on by
> > default and in v5.40 would become mandatory. Paul Evans has recently
> > reminded us of just how much that does.[2] People would have five
> > years to get ready for the end of support of 5.38.x, including getting
> > CPAN and the toolchain into a form where a module version can specify
> > the minimum and maximum Perl versions it supports. Meanwhile, v5.34
> > could announce a new feature bundle to be enabled in v5.38 and
> > mandatory in v5.42. Lather, rinse, repeat. And possibly rename 5.40.0
> > to 7.0.0 and use a new major version whenever a new feature bundle
> > becomes mandatory.
>
> I don't understand why supporting a stable Perl 5 and releasing a
> slightly more fast-moving Perl 7 are mutually exclusive.
>
> I would assume Perl 5 going into a maintenance mode long term support
> phase give users the option of adopting Perl 7 on their own timeframe
> when they are ready to do so. I would also assume that users sticking
> with Perl 5 don't want disruptive changes in Perl 5.
>
> You're saying they'll have no notice with the current plan...and that
> switching the behaviors in a minor version release will be less of a
> hassle to users than doing so across a major version release.
>
> The approach you favor is definitely more consistent with the current
> Perl 5 release practices. Whether the current release practices are
> helping the long term outlook for the Perl language seems debatable.
>
> To me, the reasonably broad support for doing something different
> (ignoring disagreements over what form that "something" should take)
> suggests that there are a lot of people who feel like the long term
> future of the Perl language is in doubt.
>
> If you don't agree with that sentiment, then indeed the status quo is
> working very well and there's no good reason to change it.
>
> If you do agree with that sentiment, then is a five year transition plan
> to Perl 7 honestly going to improve things?

The major lesson of the 5.10 era was that a steady rhythm of
predictable, modest, scheduled changes works much better than big
singleton changes of unknown scope, with an unknown impact, and on an
unknown schedule. Jesse dragged us out of that and things have gone
much more smoothly since.

The Perl 7 announcement partially addresses scope, impact, and
schedule (or at least acknowledges that these things need to be
addressed) but it is still what I am calling a singleton change, i.e.,
a one-of-a-kind event that resets the game board and ushers in a new
way of doing things. Except the announcement also mentions Perl 8,
which will presumably usher in another, incompatible, way of doing
things. If I change all my code to work under Perl 7, will I have to
change it all again when Perl 8 comes out? What will I have to
change, and when will I have to change it? The rules for how things
change are clearly changing, but what exactly are the new rules?

If it really is desirable or necessary to give up on backward
compatibility in order to move the language forward, then it seems to
me the only sane way forward is to stop thinking of backward
compatibility as a yes or no question and start thinking of it as a
"how much?" question. In my opinion, that question should have been
settled before anything else, but better late than never.

There is not a single original thought in this e-mail. It's simply
what every other mature project that does not preserve backward
compatibility indefinitely does. Java 9 broke a lot of things, but
Java 8 is still supported and people have had years of notice in both
documentation and compiler warnings about what needs to be changed and
when. Even Angular, which rewrote everything from scratch for 2.0,
breaking every single user's code in the process, has clued in to the
fact that communicating what will change and when is important. Their
pace is insane: they have a new major release every 6 months and only
guarantee backward compatibility for 18 months, but *at least they
tell you* what you will need to change and when.
Re: Q: what the hell is going on? // A: ... [ In reply to ]
Could you do me a favor, please, and reconcile assertions that Perl v5 will continue to be supported with assertions elsewhere that Perl v5 will be EOL'd when Perl v8 is released?

The Perl v7/v8 EOL'ing v5 matter is throwing a wrench in my priorities, and I'm not alone. It's got me wondering if I'd be better served migrating all of my existing projects to D and python, or something.

I expect to be programming computers for a living for at least another twenty years, and need to invest my time and energy in ways which will pay dividends in the future.

EOL'ing Perl v5 would put businesses in a difficult position where they have to keep legacy Perl running, often without enough Perl programmers on staff to port the entire mess to newer Perl, but with enough programmers to attempt porting their legacy systems to another language. That means fewer employment opportunities for professional Perl programmers.

EOL'ing Perl v5 would also jeapordize those CPAN modules which are abandoned by their authors, but still useful, which IME is most of them. CPAN's vast ocean of canned solutions remains one of Perl's greatest assets, and jeapordizing that would diminish the appeal of the language.

Users could continue to use an older release of Perl, as you have said, but as platforms evolve over time, software must eventually be updated to work on modern platforms. This effort is the minimum requirement for perpetuating Perl v5.

If someone could state for the record that as long as p5p devs are willing to continue supporting Perl v5, they will continue to have permission to make official releases, it would go a long way to allaying these fears.

The maintenance of Perl v5 can and should be a completely separate issue from releasing Perl v7, v8 or any other future version.

On Thu, Aug 6, 2020 at 18:02 Sawyer X wrote:
>
> At the moment, without any changes, we still have more than one "class
> of Perl citizens" in which one takes priority. The question is between
> those classes. These two are prominent: 1. The developer who sees
> whatever Perl they wrote never changing and 2. the developer who wants
> the best[1] Perl out of the box.
>
>
> The class that prefers no code ever be change once written is currently
> the first class of citizens. Their needs take priority to anything - new
> users, new features, bug fixes, speed optimizations, everything. It's
> true we've removed things, but rarely, and they are an exception.
> Reinstating bugs to not hurt existing code that refuses to change is
> more common and a much simpler decision in Perl.
>
>
> Any company that now picks up Perl (as if many would...), all of their
> developers (existing and new ones) must learn how to bring Perl to an
> acceptable level. They will add strict and warnings. The developers are
> already accustomed to function signatures (coming from practically any
> other language around) and will want that (if they know it exists) so
> will need to turn those on. They will eventually be bitten by bareword
> filehandles, by indirect syntax, and more. They will need to learn about
> them as they get bitten and learn to avoid them, debug obscure messages,
> and perhaps add additional pragmas to disable them - see "bring Perl to
> an acceptable level."
>
>
> That company that is trying to increase the use of Perl and build new
> things, as well as all of its developers, are second class citizens. Not
> in the dystopia future people are pontificating about, but right now.
> They currently matter less to the Perl language. The first class
> citizens are first class because they get a free ride with no changes at
> the cost of these developers above. In fact, we're signaling to this
> company that picking up Perl is not in the interest of the Perl language
> developers themselves. The community, in supporting this "balance," is
> signaling that Perl is not for anything new - which strongly contradicts
> all the conferences, blog posts, and pamphlets we tried pushing forward
> over the years. (Although, there are people who wish the language stay
> put - no new releases even. I'm going to avoid them for now, since
> they're welcome to use an old version of Perl - 5.6 is still available.)
>
>
> It seems like you're assuming that these developers who request their
> code never change are not coming at any expense, but this is simply not
> true. Of course, it's a bit silly when this argument is made and the
> response is "So we break everything?" as if anyone even suggested moving
> to the other extreme. We've done this. It exists. It's called Raku and
> it's great. But it isn't Perl. (Arguably, for a reason. :))
>
>
> Our position used to be "it can be broken and it can require everyone to
> continuously work around it till infinity, but code once written is
> king."[2] We all understand this argument. Considering this evidently
> isn't helping Perl grow (and in fact makes it all the more reason to
> just rewrite existing Perl code than continue developing it - not to
> mention picking up Perl), that position needs to be challenged. Far
> beyond "should we? Nah? Okay," but much more strongly challenged. That's
> what we did at Perl Core Summits and that's what this is about.
>
>
> [1] "Best" is subjective. Here I'm referring to "using the best
> practices and patterns that we teach and recommend (like strict and
> warnings) and having new capabilities we introduced." In "new
> capabilities" I'm thinking more about current_sub (__SUB__), rather than
> "say".
Re: Q: what the hell is going on? // A: ... [ In reply to ]
On 8/9/20 3:56 PM, TTK Ciar wrote:
> Could you do me a favor, please, and reconcile assertions that Perl v5 will continue to be supported with assertions elsewhere that Perl v5 will be EOL'd when Perl v8 is released?
>

I do not know who is making those assertions. I have not heard them.
Could you please cite a specific source so that we might respond to your
concerns?

Thank you very much.
Jim Keenan
Re: Q: what the hell is going on? // A: ... [ In reply to ]
Certainly! I am referring specifically to http://blogs.perl.org/users/leon_timmermans/2020/08/perl7-is-a-fork-of-values.html and the discussion about it at https://old.reddit.com/r/perl/comments/i1qqxa/perl7_is_a_fork_of_values/ where p5p devs expressed related concerns.

If something was lost in translation, I would be very grateful for clarification.

On Sun, Aug 09, 2020 at 05:02:08PM -0400, James E Keenan wrote:
> On 8/9/20 3:56 PM, TTK Ciar wrote:
> >Could you do me a favor, please, and reconcile assertions that Perl v5
> >will continue to be supported with assertions elsewhere that Perl v5 will
> >be EOL'd when Perl v8 is released?
> >
>
> I do not know who is making those assertions. I have not heard them.
> Could you please cite a specific source so that we might respond to your
> concerns?
>
> Thank you very much.
> Jim Keenan

1 2  View All