develooper Front page | perl.perl5.porters | Postings from April 2021

{RFC} Should we "cancel" Perl 7?

Thread Next
From:
B. Estrade
Date:
April 14, 2021 15:58
Subject:
{RFC} Should we "cancel" Perl 7?
Message ID:
31703d54-1bc3-779d-fec6-b4bbdd45fc51@cpanel.net
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








Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About