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