Mailing List Archive

{RFC} Should we "cancel" Perl 7?
I feel like this is an obvious question. This is painful yes, but the
trauma I see coming along our current path is far, far worse.

What part of the essence of the "Perl 7" plan actually requires a change
in version major version number? It is truly superficial 'public
relations' just to generate "buzz"? Because, guess what we press *right
now* - negative press, but press nonetheless.

Give that the actual major version number is literally window dressing,
I'd like to high light the parts it doesn't give us:

* there's some building consensus on 'use vX'
* there's a strong desire to "fix" the how aggressive *new* features are
added (see [0])

If the commitment to the above are fulfilled, what value add is the name
"perl 7"? I don't know, which is why I am asking.

I do have an opinion on the costs of creating a "Perl 7". This is only
my opinion, but it does go to the *hard* question I as in the subject.

What follows is a cost/benefit analysis, based on a best effort on my part.

Some Real Benefit of name change:

1. marketing juice (+/-, press is press and there is no such thing as
negative press...right?)
2. more clearly defined handling of "versions" semantics and process
improvements regarding the management of new features and deprecation of
very clearly defined "misfeatures"

Some Real Costs of name change:

1. arbitrary and cancerous points of contention not related to features
or "advancing" perl; for example:

/usr/bin/perl vs /usr/bin/perl7

Incidentally this was the flash point for all perl6 resistance, which
eventually lead to the name change (IMO). I am choosing to not discuss
how dangerously close we are to having another "perl 6" situation on our
hands, but one more of those and it could very well be the final nail
for the community.

The trauma that the community and individuals experienced because the
the perl6 thing, can only IMO be described as trauma of the most
violent. Real, disturbing trauma. Not more than a few months passed
after perl6 was renamed to Raku, that the "perl 7" initiative. Why? This
was done either out of ignorance or purposefully to kick the perl
community when it was down. Assuming that former and having zero basis
to argue the latter; the effect is the same - reliving the same trauma,
dealing with a more submissive community, etc. This is as disgusting as
it gets, folks. Refuse to be victims. Refused to abused, again.

Steps that were taking after Perl6 was renamed should have been to heal.
Any moron can see that a name change would inflict the same trauma; only
this time, it'd be oh so much easier. These are actions of people trying
to destroy a strong community. Divide and conquer; traumatize; rinse and
repeat. It's sick. All of the goals for "perl 7" can be achieved with
out the name "perl 7".

We don't need a name. We need to commit to a sane process that marshals
in new features; one that as well as possible naturally handles the
trial period (already started working on this documentation with another
community member to describe the current process!). The goal here,
again; is to stop wasting everyone's time and mental well being. It
doesn't have to be this way.

2. a lot of work, for a lot of people for just the name change; for
example, but not limited to:

* OS distribution and package maintainers
* developers making superficial changes (e.g., s/Perl 5/Perl 7/ in all
the perl docs, perl comments)
* developers and admins maintaining websites, forums, email lists (e.g;
when are we archiving this email list, perl5-porters@ and starting up
perl7-porters@?)
* infrastructure changes that have made assumptions regarding the string
'perl5' or some variation; surely we can't account for all of this - we
can only do our best to ensure code keeps running

3. Flirting with disaster and community suicide, again. opportunities
for adversaries of perl (and they come in *many* forms, worst is that
most don't even recognize they are one!) to leverage the periods of
"weakness" and further encourage internal discord [which is how strong
communities are actually defeated]

Analysis

Based on my subjected break down of costs and benefits above, my
conclusion is this:

0. drop this "perl 7" bullshit and NEVER, EVER consider a major version
change EVER, EVER, EVER AGAIN; it inviting cancer, new trauma, old
trauma, community divorce, community suicide, etc - it is FAR worse than
useless. It is HARMFUL. We can get all the good that's come out of the
"perl 7" discourse without the work needed for numerical decoration. The
vapid name change for change's sake is not worth the costs, they run
way, way too deeply. This is inhumane and unkind to the perl community;
we need to be HUMANE and kind.

1. continue to form consensus and sanity for new versions, new feature
pathways (including the actual need for 'experimentals') that do not
salt the earth as you march ahead, commitment to consistent and proper
management of deprecation

2. take the energy that we that we save to work out a new feature
path/deprecation management - this is the SINGLE area in which I believe
that the 'good of the perl' is more important than technical hurdles; if
we build consensus around what the most sane, healthy, and kind
processes look like and there is a technical roadblock in the way, MOVE
IT. It is worth it.

An example here is one I pointed out yesterday: embrace what prototypes
give us, extend them to support things like "infix" (and postfix,
circumfix) since this does provide a real new dimension of semantic
exploration we do not have without "adding a feature to core" ( I think
). Suddenly there's very little technical reasons to not go the: CPAN ->
dual life route form a large percentage of existing experimental features.

Some _DO_ require this, no doubt. My only point - maximize the
CPAN->"dual life"; ruthlessly minimize core changes for "features" and
focus more on making "core" such that it is easy, FUN, and interesting
to try new features - again, as a CPAN module.

I believe step 1 is documenting some sort of process, for RFC. This is
my skin in the game for now.

3. Final point here, is really a restatement. I can see no benefit from
the version name change. There is value in what the "change" was meant
to represent. However, we can have the change without the useless work
to make the name change happen.

The PRC has recently and very clearly recommitted to 'backward
compatibility'. Amen. This must be extended to the one remaining time
bomb. The major version change.

So let's drop the one thing about "perl 7" that is not only useless, but
harmful. The name. And more than that, promise to never bring it up again.

Thank you,
Brett
Re: {RFC} Should we "cancel" Perl 7? [ In reply to ]
On Wed, Apr 14, 2021 at 11:59 AM B. Estrade <brett@cpanel.net> wrote:

> I feel like this is an obvious question. This is painful yes, but the
> trauma I see coming along our current path is far, far worse.
>
> What part of the essence of the "Perl 7" plan actually requires a change
> in version major version number? It is truly superficial 'public
> relations' just to generate "buzz"? Because, guess what we press *right
> now* - negative press, but press nonetheless.
>
> Give that the actual major version number is literally window dressing,
> I'd like to high light the parts it doesn't give us:
>
> * there's some building consensus on 'use vX'
> * there's a strong desire to "fix" the how aggressive *new* features are
> added (see [0])
>
> If the commitment to the above are fulfilled, what value add is the name
> "perl 7"? I don't know, which is why I am asking.
>
> I do have an opinion on the costs of creating a "Perl 7". This is only
> my opinion, but it does go to the *hard* question I as in the subject.
>
> What follows is a cost/benefit analysis, based on a best effort on my part.
>
> Some Real Benefit of name change:
>
> 1. marketing juice (+/-, press is press and there is no such thing as
> negative press...right?)
> 2. more clearly defined handling of "versions" semantics and process
> improvements regarding the management of new features and deprecation of
> very clearly defined "misfeatures"
>
> Some Real Costs of name change:
>
> 1. arbitrary and cancerous points of contention not related to features
> or "advancing" perl; for example:
>
> /usr/bin/perl vs /usr/bin/perl7
>
> Incidentally this was the flash point for all perl6 resistance, which
> eventually lead to the name change (IMO). I am choosing to not discuss
> how dangerously close we are to having another "perl 6" situation on our
> hands, but one more of those and it could very well be the final nail
> for the community.
>
> The trauma that the community and individuals experienced because the
> the perl6 thing, can only IMO be described as trauma of the most
> violent. Real, disturbing trauma. Not more than a few months passed
> after perl6 was renamed to Raku, that the "perl 7" initiative. Why? This
> was done either out of ignorance or purposefully to kick the perl
> community when it was down. Assuming that former and having zero basis
> to argue the latter; the effect is the same - reliving the same trauma,
> dealing with a more submissive community, etc. This is as disgusting as
> it gets, folks. Refuse to be victims. Refused to abused, again.
>
> Steps that were taking after Perl6 was renamed should have been to heal.
> Any moron can see that a name change would inflict the same trauma; only
> this time, it'd be oh so much easier. These are actions of people trying
> to destroy a strong community. Divide and conquer; traumatize; rinse and
> repeat. It's sick. All of the goals for "perl 7" can be achieved with
> out the name "perl 7".
>
> We don't need a name. We need to commit to a sane process that marshals
> in new features; one that as well as possible naturally handles the
> trial period (already started working on this documentation with another
> community member to describe the current process!). The goal here,
> again; is to stop wasting everyone's time and mental well being. It
> doesn't have to be this way.
>
> 2. a lot of work, for a lot of people for just the name change; for
> example, but not limited to:
>
> * OS distribution and package maintainers
> * developers making superficial changes (e.g., s/Perl 5/Perl 7/ in all
> the perl docs, perl comments)
> * developers and admins maintaining websites, forums, email lists (e.g;
> when are we archiving this email list, perl5-porters@ and starting up
> perl7-porters@?)
> * infrastructure changes that have made assumptions regarding the string
> 'perl5' or some variation; surely we can't account for all of this - we
> can only do our best to ensure code keeps running
>
> 3. Flirting with disaster and community suicide, again. opportunities
> for adversaries of perl (and they come in *many* forms, worst is that
> most don't even recognize they are one!) to leverage the periods of
> "weakness" and further encourage internal discord [which is how strong
> communities are actually defeated]
>
> Analysis
>
> Based on my subjected break down of costs and benefits above, my
> conclusion is this:
>
> 0. drop this "perl 7" bullshit and NEVER, EVER consider a major version
> change EVER, EVER, EVER AGAIN; it inviting cancer, new trauma, old
> trauma, community divorce, community suicide, etc - it is FAR worse than
> useless. It is HARMFUL. We can get all the good that's come out of the
> "perl 7" discourse without the work needed for numerical decoration. The
> vapid name change for change's sake is not worth the costs, they run
> way, way too deeply. This is inhumane and unkind to the perl community;
> we need to be HUMANE and kind.
>
> 1. continue to form consensus and sanity for new versions, new feature
> pathways (including the actual need for 'experimentals') that do not
> salt the earth as you march ahead, commitment to consistent and proper
> management of deprecation
>
> 2. take the energy that we that we save to work out a new feature
> path/deprecation management - this is the SINGLE area in which I believe
> that the 'good of the perl' is more important than technical hurdles; if
> we build consensus around what the most sane, healthy, and kind
> processes look like and there is a technical roadblock in the way, MOVE
> IT. It is worth it.
>
> An example here is one I pointed out yesterday: embrace what prototypes
> give us, extend them to support things like "infix" (and postfix,
> circumfix) since this does provide a real new dimension of semantic
> exploration we do not have without "adding a feature to core" ( I think
> ). Suddenly there's very little technical reasons to not go the: CPAN ->
> dual life route form a large percentage of existing experimental features.
>
> Some _DO_ require this, no doubt. My only point - maximize the
> CPAN->"dual life"; ruthlessly minimize core changes for "features" and
> focus more on making "core" such that it is easy, FUN, and interesting
> to try new features - again, as a CPAN module.
>
> I believe step 1 is documenting some sort of process, for RFC. This is
> my skin in the game for now.
>
> 3. Final point here, is really a restatement. I can see no benefit from
> the version name change. There is value in what the "change" was meant
> to represent. However, we can have the change without the useless work
> to make the name change happen.
>
> The PRC has recently and very clearly recommitted to 'backward
> compatibility'. Amen. This must be extended to the one remaining time
> bomb. The major version change.
>
> So let's drop the one thing about "perl 7" that is not only useless, but
> harmful. The name. And more than that, promise to never bring it up again.
>

The value is not in the name but in the clear and easy to remember major
version. It is factual that almost all Perl outsiders believe that Perl has
not been developed since 5.8 because they see no difference in the version
number. I do not think we should abandon the opportunity to correct this
perception because of some unrelated sore points. Of course there is plenty
of effort required to fix major version assumptions, but this has already
started and I believe is worthwhile regardless.

-Dan
Re: {RFC} Should we "cancel" Perl 7? [ In reply to ]
No

On Wed, Apr 14, 2021, 12:58 B. Estrade <brett@cpanel.net> wrote:

> I feel like this is an obvious question. This is painful yes, but the
> trauma I see coming along our current path is far, far worse.
>
> What part of the essence of the "Perl 7" plan actually requires a change
> in version major version number? It is truly superficial 'public
> relations' just to generate "buzz"? Because, guess what we press *right
> now* - negative press, but press nonetheless.
>
> Give that the actual major version number is literally window dressing,
> I'd like to high light the parts it doesn't give us:
>
> * there's some building consensus on 'use vX'
> * there's a strong desire to "fix" the how aggressive *new* features are
> added (see [0])
>
> If the commitment to the above are fulfilled, what value add is the name
> "perl 7"? I don't know, which is why I am asking.
>
> I do have an opinion on the costs of creating a "Perl 7". This is only
> my opinion, but it does go to the *hard* question I as in the subject.
>
> What follows is a cost/benefit analysis, based on a best effort on my part.
>
> Some Real Benefit of name change:
>
> 1. marketing juice (+/-, press is press and there is no such thing as
> negative press...right?)
> 2. more clearly defined handling of "versions" semantics and process
> improvements regarding the management of new features and deprecation of
> very clearly defined "misfeatures"
>
> Some Real Costs of name change:
>
> 1. arbitrary and cancerous points of contention not related to features
> or "advancing" perl; for example:
>
> /usr/bin/perl vs /usr/bin/perl7
>
> Incidentally this was the flash point for all perl6 resistance, which
> eventually lead to the name change (IMO). I am choosing to not discuss
> how dangerously close we are to having another "perl 6" situation on our
> hands, but one more of those and it could very well be the final nail
> for the community.
>
> The trauma that the community and individuals experienced because the
> the perl6 thing, can only IMO be described as trauma of the most
> violent. Real, disturbing trauma. Not more than a few months passed
> after perl6 was renamed to Raku, that the "perl 7" initiative. Why? This
> was done either out of ignorance or purposefully to kick the perl
> community when it was down. Assuming that former and having zero basis
> to argue the latter; the effect is the same - reliving the same trauma,
> dealing with a more submissive community, etc. This is as disgusting as
> it gets, folks. Refuse to be victims. Refused to abused, again.
>
> Steps that were taking after Perl6 was renamed should have been to heal.
> Any moron can see that a name change would inflict the same trauma; only
> this time, it'd be oh so much easier. These are actions of people trying
> to destroy a strong community. Divide and conquer; traumatize; rinse and
> repeat. It's sick. All of the goals for "perl 7" can be achieved with
> out the name "perl 7".
>
> We don't need a name. We need to commit to a sane process that marshals
> in new features; one that as well as possible naturally handles the
> trial period (already started working on this documentation with another
> community member to describe the current process!). The goal here,
> again; is to stop wasting everyone's time and mental well being. It
> doesn't have to be this way.
>
> 2. a lot of work, for a lot of people for just the name change; for
> example, but not limited to:
>
> * OS distribution and package maintainers
> * developers making superficial changes (e.g., s/Perl 5/Perl 7/ in all
> the perl docs, perl comments)
> * developers and admins maintaining websites, forums, email lists (e.g;
> when are we archiving this email list, perl5-porters@ and starting up
> perl7-porters@?)
> * infrastructure changes that have made assumptions regarding the string
> 'perl5' or some variation; surely we can't account for all of this - we
> can only do our best to ensure code keeps running
>
> 3. Flirting with disaster and community suicide, again. opportunities
> for adversaries of perl (and they come in *many* forms, worst is that
> most don't even recognize they are one!) to leverage the periods of
> "weakness" and further encourage internal discord [which is how strong
> communities are actually defeated]
>
> Analysis
>
> Based on my subjected break down of costs and benefits above, my
> conclusion is this:
>
> 0. drop this "perl 7" bullshit and NEVER, EVER consider a major version
> change EVER, EVER, EVER AGAIN; it inviting cancer, new trauma, old
> trauma, community divorce, community suicide, etc - it is FAR worse than
> useless. It is HARMFUL. We can get all the good that's come out of the
> "perl 7" discourse without the work needed for numerical decoration. The
> vapid name change for change's sake is not worth the costs, they run
> way, way too deeply. This is inhumane and unkind to the perl community;
> we need to be HUMANE and kind.
>
> 1. continue to form consensus and sanity for new versions, new feature
> pathways (including the actual need for 'experimentals') that do not
> salt the earth as you march ahead, commitment to consistent and proper
> management of deprecation
>
> 2. take the energy that we that we save to work out a new feature
> path/deprecation management - this is the SINGLE area in which I believe
> that the 'good of the perl' is more important than technical hurdles; if
> we build consensus around what the most sane, healthy, and kind
> processes look like and there is a technical roadblock in the way, MOVE
> IT. It is worth it.
>
> An example here is one I pointed out yesterday: embrace what prototypes
> give us, extend them to support things like "infix" (and postfix,
> circumfix) since this does provide a real new dimension of semantic
> exploration we do not have without "adding a feature to core" ( I think
> ). Suddenly there's very little technical reasons to not go the: CPAN ->
> dual life route form a large percentage of existing experimental features.
>
> Some _DO_ require this, no doubt. My only point - maximize the
> CPAN->"dual life"; ruthlessly minimize core changes for "features" and
> focus more on making "core" such that it is easy, FUN, and interesting
> to try new features - again, as a CPAN module.
>
> I believe step 1 is documenting some sort of process, for RFC. This is
> my skin in the game for now.
>
> 3. Final point here, is really a restatement. I can see no benefit from
> the version name change. There is value in what the "change" was meant
> to represent. However, we can have the change without the useless work
> to make the name change happen.
>
> The PRC has recently and very clearly recommitted to 'backward
> compatibility'. Amen. This must be extended to the one remaining time
> bomb. The major version change.
>
> So let's drop the one thing about "perl 7" that is not only useless, but
> harmful. The name. And more than that, promise to never bring it up again.
>
> Thank you,
> Brett
>
>
>
>
>
>
>
>
Re: {RFC} Should we "cancel" Perl 7? [ In reply to ]
On 4/14/21 11:07 AM, Dan Book wrote:
> On Wed, Apr 14, 2021 at 11:59 AM B. Estrade <brett@cpanel.net
> <mailto:brett@cpanel.net>> wrote:
>
<snip>
>
> The value is not in the name but in the clear and easy to remember major
> version. It is factual that almost all Perl outsiders believe that Perl
> has not been developed since 5.8 because they see no difference in the
> version number. I do not think we should abandon the opportunity to
> correct this perception because of some unrelated sore points. Of course
> there is plenty of effort required to fix major version assumptions, but
> this has already started and I believe is worthwhile regardless.
>

Thank you. This *is* a value and have added it to my "list". Speaking of
opportunities, my only hope with the email - which was very difficult
for me to "put out there" - is that the question got asked and there was
a real opportunity to consider it. My opinions are just mine. I will
continue to help and be part of things regardless. Because no matter
what, I want perl to succeed - whatever that ends up looking like. And
really, that's how I want everyone to be. I also want there to be a real
healing; and it necessarily must be manifested through the creation of
digital artifacts. These are my true goals.

Cheers,
Brett

> -Dan
Re: {RFC} Should we "cancel" Perl 7? [ In reply to ]
On Wed, 14 Apr 2021 12:07:04 -0400
Dan Book <grinnz@gmail.com> wrote:

> The value is not in the name but in the clear and easy to remember
> major version. It is factual that almost all Perl outsiders believe
> that Perl has not been developed since 5.8 because they see no
> difference in the version number. I do not think we should abandon
> the opportunity to correct this perception because of some unrelated
> sore points. Of course there is plenty of effort required to fix
> major version assumptions, but this has already started and I believe
> is worthwhile regardless.

+1.

A major part of any facet of a "Perl 7" plan was the idea that
"version 7" signals quite a big change to users. The embodiment here is
that

use v7;

can invoke a lot of new exciting differences - introduce major new
features like signatures, try/catch, etc... as well as turn off many of
the legacy behaviours we'd like to get rid of - indirect, bareword
filehandles, etc..

We've always been able to do that with v5.x and in the short term until
a v7 bundle is ready, we can continue to do that. The advantage that 7
has is that it's a short, neat, convenient way to remember "all those
nice things" that came along at that point.

I touched upon that very point in my recent "Perl in 2025" talk for
FOSDEM (and repeated for GPW); you can see the entire 35minute video at

https://video.fosdem.org/2021/D.perl/perl_in_2025.mp4
https://video.fosdem.org/2021/D.perl/perl_in_2025.webm

or just skip to the 31:40 timestamp to get to these specific closing
points.

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Re: {RFC} Should we "cancel" Perl 7? [ In reply to ]
On Wed, 14 Apr 2021, B. Estrade wrote:

> Why? This was done either out of
> ignorance or purposefully to kick the perl community when it was down.
> Assuming that former and having zero basis to argue the latter; [...]

So you say you have no arguments to argue the "purposefully kicking down",
and then a few sentences later you say this:

> [...] These are actions of people trying to destroy a strong community.

Was this allegation really necessary to make your point?

I didn't have time to follow all discussions since last year's announcement,
but I think this wasn't the only occasion that someone claimed that
the supporters of the original plan, and especially Sawyer, are trying to
destroy Perl.

This doesn't help a friendly discussion, and, seriously, do some people really
believe that?
I think there are easier, less time consuming ways to destroy Perl, if one
really wanted that.

There are different opinions on how things should be done, but not because
group A loves Perl and group B hates Perl, but because everyone loves
Perl in their own way.
It is not necessary to assume the worst intentions from the others when trying
to make your point.
Or, if you assume so, then at least keep it to yourself. It doesn't help the
discussion, and it makes people sad [1].

cheers,
tina

[1] I have been a perl forum maintainer and moderator and monger group leader
for many years, and even if I tried to not take things personally
from persons I don't personally know, it was hard sometimes.
Re: {RFC} Should we "cancel" Perl 7? [ In reply to ]
On 4/14/21 12:06 PM, Tina Müller wrote:
> On Wed, 14 Apr 2021, B. Estrade wrote:
>
>> Why? This was done either out of ignorance or purposefully to kick the
>> perl community when it was down. Assuming that former and having zero
>> basis to argue the latter; [...]
>
> So you say you have no arguments to argue the "purposefully kicking down",
> and then a few sentences later you say this:
>
>> [...] These are actions of people trying to destroy a strong community.
>
> Was this allegation really necessary to make your point?
>
> I didn't have time to follow all discussions since last year's
> announcement,
> but I think this wasn't the only occasion that someone claimed that
> the supporters of the original plan, and especially Sawyer, are trying to
> destroy Perl.

You are putting words in my mouth and this is a gross characterization.

>
> This doesn't help a friendly discussion, and, seriously, do some people
> really
> believe that?
> I think there are easier, less time consuming ways to destroy Perl, if one
> really wanted that.

These statements are not mutually exclusive. Just some projection on my
part. The lack of context might also cause some confusion.

A mental model of an "unseen enemy" is not harmful unless it's used to
justify a witch hunt, which could not be further from my intent. That
also doesn't mean I think there is one. But I do question the wisdom;
attributing to it ignorance over malevolence. Do we have room for such
considerations? Is there a reasonable middle ground that admits neither
ignorance nor malevolence? I don't know. Nonetheless, I do not think
there is malicious intent.

As I said in another email, mental models are only worth their
effectiveness on moving to a solution.

>
> There are different opinions on how things should be done, but not because
> group A loves Perl and group B hates Perl, but because everyone loves
> Perl in their own way.
> It is not necessary to assume the worst intentions from the others when
> trying
> to make your point.

If we must argue about my wording and personal mental model, then that
will not be fruitful. Everyone looks at things differently. Our goals
are the same, no doubt.

> Or, if you assume so, then at least keep it to yourself. It doesn't help
> the
> discussion, and it makes people sad [1].

Sadness, pain, wasted time - these are all things I am seeking to avoid
as well. healing.

That said, I appreciate all you do and I have followed your work
enthusiastically over the years. The spirit of innovation is very
important to perl at large. And its examples like this that give me hope
that there's enough creativity left to forge a way forward. I recognize
the role of strawman, and am happy to play that part.

Sincerely,
Brett

>
> cheers,
> tina
>
> [1] I have been a perl forum maintainer and moderator and monger group
> leader
> for many years, and even if I tried to not take things personally
> from persons I don't personally know, it was hard sometimes.
Re: {RFC} Should we "cancel" Perl 7? [ In reply to ]
On Wed, Apr 14, 2021 at 10:58:42AM -0500, B. Estrade wrote:
> I feel like this is an obvious question. This is painful yes, but the trauma
> I see coming along our current path is far, far worse.

No.

You are very wrong.

1) It is the remit of the steering committee to decide this. *
2) They have just decided a plan (I believe unanimously) as described here:

https://www.nntp.perl.org/group/perl.perl5.porters/2021/04/msg259789.html

This plan stands.

It should be obvious that this plan stands, as it was approved unanimously,
and 2 of the 3 people who created it remain in their positions.

I am not on the steering committee, but I am standing in the election to
fill the vacant third seat for the rest of this "term" (which ends once
perl 5.34.0 is released). Strictly "what would I do on this?" is not covered
by my manifesto** but I am happy to go on the record and say that if I am
elected to the committee I will back this plan, and not seek to re-litigate
what has already been resolved.

Until there is material change in circumstances, it's a waste of everyone's
time to keep talking about things that have been decided.

Nicholas Clark

* https://github.com/Perl/perl5/blob/blead/pod/perlgov.pod
** See https://perl.topicbox.com/groups/perl-core/T5807c06f2255d0f0-Md815f6b12a3a0622fd418e8b
Re: {RFC} Should we "cancel" Perl 7? [ In reply to ]
On Wed, Apr 14, 2021 at 05:32:29PM +0100, Paul "LeoNerd" Evans wrote:
> On Wed, 14 Apr 2021 12:07:04 -0400
> Dan Book <grinnz@gmail.com> wrote:
>
> > The value is not in the name but in the clear and easy to remember
> > major version. It is factual that almost all Perl outsiders believe
> > that Perl has not been developed since 5.8 because they see no
> > difference in the version number. I do not think we should abandon
> > the opportunity to correct this perception because of some unrelated
> > sore points. Of course there is plenty of effort required to fix
> > major version assumptions, but this has already started and I believe
> > is worthwhile regardless.
>
> +1.
>
> A major part of any facet of a "Perl 7" plan was the idea that
> "version 7" signals quite a big change to users. The embodiment here is
> that
>
> use v7;
>
> can invoke a lot of new exciting differences - introduce major new
> features like signatures, try/catch, etc... as well as turn off many of
> the legacy behaviours we'd like to get rid of - indirect, bareword
> filehandles, etc..

I feel like removing behaviors is an important part of this. With this
we can use the semi-standard that "minor" versions are forward compatible.
By that I mean, changing `use v7` to `use v7.3` shouldn't _break_ the
existing code, but just enable new features, while changing to `use v8`
might mean you have to change the existing code.

I don't know if that's a planned difference, but one that might make it
more likely that I would use the newer features.

Obviously if someone added a new keyword that might conflict, so I don't
think it's 100% true, but I would expect we could get a "$keyword
redefined at line $x" warning in that case.


l8rZ,
--
andrew - http://afresh1.com

Unix is very simple,
but it takes a genius to understand the simplicity.
-- Dennis Ritchie
Re: {RFC} Should we "cancel" Perl 7? [ In reply to ]
On Wed, Apr 14, 2021 at 2:51 PM Andrew Hewus Fresh <andrew@afresh1.com>
wrote:

> On Wed, Apr 14, 2021 at 05:32:29PM +0100, Paul "LeoNerd" Evans wrote:
> > On Wed, 14 Apr 2021 12:07:04 -0400
> > Dan Book <grinnz@gmail.com> wrote:
> >
> > > The value is not in the name but in the clear and easy to remember
> > > major version. It is factual that almost all Perl outsiders believe
> > > that Perl has not been developed since 5.8 because they see no
> > > difference in the version number. I do not think we should abandon
> > > the opportunity to correct this perception because of some unrelated
> > > sore points. Of course there is plenty of effort required to fix
> > > major version assumptions, but this has already started and I believe
> > > is worthwhile regardless.
> >
> > +1.
> >
> > A major part of any facet of a "Perl 7" plan was the idea that
> > "version 7" signals quite a big change to users. The embodiment here is
> > that
> >
> > use v7;
> >
> > can invoke a lot of new exciting differences - introduce major new
> > features like signatures, try/catch, etc... as well as turn off many of
> > the legacy behaviours we'd like to get rid of - indirect, bareword
> > filehandles, etc..
>
> I feel like removing behaviors is an important part of this. With this
> we can use the semi-standard that "minor" versions are forward
> compatible.
> By that I mean, changing `use v7` to `use v7.3` shouldn't _break_ the
> existing code, but just enable new features, while changing to `use v8`
> might mean you have to change the existing code.
>
> I don't know if that's a planned difference, but one that might make it
> more likely that I would use the newer features.
>
> Obviously if someone added a new keyword that might conflict, so I don't
> think it's 100% true, but I would expect we could get a "$keyword
> redefined at line $x" warning in that case.
>

If features could be added without breaking the existing code, then we
wouldn't have had much of the disagreement over the past year.

Anything that can be reasonably changed via a deprecation process method,
or because the syntax is currently invalid, can be changed without any
declaration, as it has done in the past.

-Dan
Re: {RFC} Should we "cancel" Perl 7? [ In reply to ]
On Wed, 14 Apr 2021, B. Estrade wrote:

> On 4/14/21 12:06 PM, Tina M?ller wrote:
>> On Wed, 14 Apr 2021, B. Estrade wrote:
>>
>>> Why? This was done either out of ignorance or purposefully to kick the
>>> perl community when it was down. Assuming that former and having zero
>>> basis to argue the latter; [...]
>>
>> So you say you have no arguments to argue the "purposefully kicking down",
>> and then a few sentences later you say this:
>>
>>> [...] These are actions of people trying to destroy a strong community.
>>
>> Was this allegation really necessary to make your point?
>>
>> I didn't have time to follow all discussions since last year's
>> announcement,
>> but I think this wasn't the only occasion that someone claimed that
>> the supporters of the original plan, and especially Sawyer, are trying to
>> destroy Perl.
>
> You are putting words in my mouth and this is a gross characterization.

I'm sorry. I read your email again, but still don't see where I understood
it wrong. Maybe a translation issue.

If you didn't mean it like that, then my comment is aimed at least at
others having claimed this.

cheers,
tina
Re: {RFC} Should we "cancel" Perl 7? [ In reply to ]
On Wed, Apr 14, 2021 at 02:57:43PM -0400, Dan Book wrote:
> On Wed, Apr 14, 2021 at 2:51 PM Andrew Hewus Fresh <andrew@afresh1.com>
> > I feel like removing behaviors is an important part of this. With this
> > we can use the semi-standard that "minor" versions are forward
> > compatible.
> > By that I mean, changing `use v7` to `use v7.3` shouldn't _break_ the
> > existing code, but just enable new features, while changing to `use v8`
> > might mean you have to change the existing code.
> >
> > I don't know if that's a planned difference, but one that might make it
> > more likely that I would use the newer features.
> >
> > Obviously if someone added a new keyword that might conflict, so I don't
> > think it's 100% true, but I would expect we could get a "$keyword
> > redefined at line $x" warning in that case.
> >
>
> If features could be added without breaking the existing code, then we
> wouldn't have had much of the disagreement over the past year.
>
> Anything that can be reasonably changed via a deprecation process method,
> or because the syntax is currently invalid, can be changed without any
> declaration, as it has done in the past.

I guess I was mostly thinking of things that would have been syntax
errors before, like `'foo' equ 'bar'` or `$arrayref->@*` but where
`use v5.24` gives a better error than "Array found where operator
expected".

Maybe with the ability to have major version bumps, `use feature 'isa'`
would have waited to be part of a bundle until the next major version.

Not really sure, other than opportunities to make things less painful to
update and encourage people to add `use vX` abound.

l8rZ,
--
andrew - http://afresh1.com

Full-time system administration is a delicate balance
between proactiveness and laziness.
-- jhorwitz from use.perl.org
Re: {RFC} Should we "cancel" Perl 7? [ In reply to ]
It seems to me that a main thing we want to avoid is conflating product names
with regular version numbers. So doing away with calling "Perl 7" a new product
I agree with. But we should still be free to use higher version numbers.

So the product is "Perl" full stop, NOT "Perl 5" or any other "Perl N". And
maintainers can be free to use any major version numbers for "Perl" whether 5 or
something higher. (But we still skip using 6.)

On 2021-04-14 8:58 a.m., B. Estrade wrote:
> Some Real Costs of name change:
>
> 1. arbitrary and cancerous points of contention not related to features or
> "advancing" perl; for example:
>
> /usr/bin/perl vs /usr/bin/perl7

The solution is to just have /user/bin/perl and that's it.

A perl5 alias could exist indefinitely for backwards compatibility, and notably
that would remain the same no matter what the actual version of Perl is. There
would never be a perl7 or whatever.

> 2. a lot of work, for a lot of people for just the name change; for example, but
> not limited to:
>
> * developers making superficial changes (e.g., s/Perl 5/Perl 7/ in all the perl
> docs, perl comments)

No, you just remove the 5 everywhere, changing "Perl 5" to "Perl" and then it
never changes again.

> * developers and admins maintaining websites, forums, email lists (e.g; when are
> we archiving this email list, perl5-porters@ and starting up perl7-porters@?)

Either we keep the perl5-porters name or a rename is perl-porters or something
else without any number.

> Based on my subjected break down of costs and benefits above, my conclusion is
> this:
>
> 0. drop this "perl 7" bullshit and NEVER, EVER consider a major version change
> EVER, EVER, EVER AGAIN; ...
>
> 1. continue to form consensus and sanity for new versions, new feature pathways
> (including the actual need for 'experimentals') that do not salt the earth as
> you march ahead, commitment to consistent and proper management of deprecation

I see that you just contradicted yourself here, or at least that's how I read it
as "form consensus and sanity for new version [number]s".

But that interpretation is what I advocate myself.

Consensus and sanity with the developers can choose to use any version number
they feel is appropriate, whether it is 5.x or some other y.x and they should
all be treated in the same manner.

-- Darren Duncan
Re: {RFC} Should we "cancel" Perl 7? [ In reply to ]
Or perhaps go to a date based numbering system (v20210415 for example) as
a promise that there will never be backward compatibility issues between
releases - backwards compatibility being one of the great strengths of
Perl.

On Thu, Apr 15, 2021 at 2:17 AM Darren Duncan <darren@darrenduncan.net>
wrote:

> It seems to me that a main thing we want to avoid is conflating product
> names
> with regular version numbers. So doing away with calling "Perl 7" a new
> product
> I agree with. But we should still be free to use higher version numbers.
>
> So the product is "Perl" full stop, NOT "Perl 5" or any other "Perl N".
> And
> maintainers can be free to use any major version numbers for "Perl"
> whether 5 or
> something higher. (But we still skip using 6.)
>
> On 2021-04-14 8:58 a.m., B. Estrade wrote:
> > Some Real Costs of name change:
> >
> > 1. arbitrary and cancerous points of contention not related to features
> or
> > "advancing" perl; for example:
> >
> > /usr/bin/perl vs /usr/bin/perl7
>
> The solution is to just have /user/bin/perl and that's it.
>
> A perl5 alias could exist indefinitely for backwards compatibility, and
> notably
> that would remain the same no matter what the actual version of Perl is.
> There
> would never be a perl7 or whatever.
>
> > 2. a lot of work, for a lot of people for just the name change; for
> example, but
> > not limited to:
> >
> > * developers making superficial changes (e.g., s/Perl 5/Perl 7/ in all
> the perl
> > docs, perl comments)
>
> No, you just remove the 5 everywhere, changing "Perl 5" to "Perl" and then
> it
> never changes again.
>
> > * developers and admins maintaining websites, forums, email lists (e.g;
> when are
> > we archiving this email list, perl5-porters@ and starting up
> perl7-porters@?)
>
> Either we keep the perl5-porters name or a rename is perl-porters or
> something
> else without any number.
>
> > Based on my subjected break down of costs and benefits above, my
> conclusion is
> > this:
> >
> > 0. drop this "perl 7" bullshit and NEVER, EVER consider a major version
> change
> > EVER, EVER, EVER AGAIN; ...
> >
> > 1. continue to form consensus and sanity for new versions, new feature
> pathways
> > (including the actual need for 'experimentals') that do not salt the
> earth as
> > you march ahead, commitment to consistent and proper management of
> deprecation
>
> I see that you just contradicted yourself here, or at least that's how I
> read it
> as "form consensus and sanity for new version [number]s".
>
> But that interpretation is what I advocate myself.
>
> Consensus and sanity with the developers can choose to use any version
> number
> they feel is appropriate, whether it is 5.x or some other y.x and they
> should
> all be treated in the same manner.
>
> -- Darren Duncan
>


--
Thanks,

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

Philip R Brenan <https://metacpan.org/author/PRBRENAN>
Re: {RFC} Should we "cancel" Perl 7? [ In reply to ]
On 2021-04-14 7:38 p.m., Philip R Brenan wrote:
> Or perhaps go to a date based numbering system  (v20210415 for example)  as a
> promise that there will never be backward compatibility issues between releases
> - backwards compatibility being one of the great strengths of Perl.

Date based version numbers don't make any kind of explicit statement at all
about compatibility. Unlike semantic versions which I prefer, date based
versions actually do the opposite, saying any release could have arbitrarily
large changes. Date based versions may have other benefits but a compatibility
statement isn't one of them. -- Darren Duncan
Re: {RFC} Should we "cancel" Perl 7? [ In reply to ]
On 4/14/21 8:17 PM, Darren Duncan wrote:
> It seems to me that a main thing we want to avoid is conflating product
> names with regular version numbers.  So doing away with calling "Perl 7"
> a new product I agree with.  But we should still be free to use higher
> version numbers.
>
> So the product is "Perl" full stop, NOT "Perl 5" or any other "Perl N".
> And maintainers can be free to use any major version numbers for "Perl"
> whether 5 or something higher.  (But we still skip using 6.)
>
> On 2021-04-14 8:58 a.m., B. Estrade wrote:
>> Some Real Costs of name change:
>>
>> 1. arbitrary and cancerous points of contention not related to
>> features or "advancing" perl; for example:
>>
>> /usr/bin/perl vs /usr/bin/perl7
>
> The solution is to just have /user/bin/perl and that's it.
>
> A perl5 alias could exist indefinitely for backwards compatibility, and
> notably that would remain the same no matter what the actual version of
> Perl is.  There would never be a perl7 or whatever.
>
>> 2. a lot of work, for a lot of people for just the name change; for
>> example, but not limited to:
>>
>> * developers making superficial changes (e.g., s/Perl 5/Perl 7/ in all
>> the perl docs, perl comments)
>
> No, you just remove the 5 everywhere, changing "Perl 5" to "Perl" and
> then it never changes again.
>
>> * developers and admins maintaining websites, forums, email lists
>> (e.g; when are we archiving this email list, perl5-porters@ and
>> starting up perl7-porters@?)
>
> Either we keep the perl5-porters name or a rename is perl-porters or
> something else without any number.
>
>> Based on my subjected break down of costs and benefits above, my
>> conclusion is this:
>>
>> 0. drop this "perl 7" bullshit and NEVER, EVER consider a major
>> version change EVER, EVER, EVER AGAIN; ...
>>
>> 1. continue to form consensus and sanity for new versions, new feature
>> pathways (including the actual need for 'experimentals') that do not
>> salt the earth as you march ahead, commitment to consistent and proper
>> management of deprecation
>
> I see that you just contradicted yourself here, or at least that's how I
> read it as "form consensus and sanity for new version [number]s".

For the sake of clarity; I wish to be internally consistent, so let me
just illustrate what I think would give us the ability to experiment
with new features.

For clarification, what I say here assumes a sane new feature pathway.
Introduce features for "market testing" in a way that they can be
removed without creating for your self a catch-22. An example,

* new features must be provided via CPAN "use Experiment::infix::doh"
becomes the most common kind of way to 'turn on' an experimental feature

* if a new feature can't be implemented using pure Perl or babby XS
bindings, then this might indicate generic support for such things is
required;

* perl "userland" - CPAN + access to friendly syscalls (via pure perl
and babby XS) - go nuts here, nobody filters CPAN for terrible ideas

* perl "kernel" - low level interpreters and run time things; black box;
necessarily implements "syscalls"

* "userland" is the wild west; changes often. CPAN is our "package
system" (duh). "kernel" implements low level things most of us have no
business touching

* CPAN -> dual life is the "dream" for anyone wanting to put a "perl
feature" on their resume; if you want to get your commit score high,
hack on the internals just don't touch my ABI (application babby interface).

Same paradigm/mental model and benefit as unix userland/kernel level
stuff. Same benefits that are provided by syscalls (maybe call them
'pyscalls' to disambiguate). Same analogies can be extended to "standard
unix userland utilities" for doing most things.

I am sure there is a FUSE or Docker (can I claim the name Pocker? now or
later?) analogy somewhere for even more "userland" overlay fun, also.

Any new perl feature should be able to be implemented with pure perl;
that's the most restrictive model. Maybe babby XS. If it takes almost
100 lines of perl API code to implement a 'trim' function when a regex
in userland would have done it, that might be an indication that
something is wrong with where you are doing it. Unless this is a
obfuscation contest, which sometimes I think it is. More like perl
putt-putt and our windmill is frozen solid.

What's the benefit? Competition. Proliferation of modules will inform on:

* what to promote
* what to ignore
* what needs to be optimized

etc - all the thing free competition brings us, enabled within the
context of traditional perl and CPAN.

Enjoy this, next stop linux kernel:

https://lkml.org/lkml/2021/4/14/1023

Ian McDiarmid: Good, good. Yes we're getting closer.

Brett xD


>
> But that interpretation is what I advocate myself.
>
> Consensus and sanity with the developers can choose to use any version
> number they feel is appropriate, whether it is 5.x or some other y.x and
> they should all be treated in the same manner.
>
> -- Darren Duncan