develooper Front page | perl.perl5.porters | Postings from July 2020

Re: Announcing Perl 7

Thread Previous | Thread Next
From:
Sawyer X
Date:
July 3, 2020 13:00
Subject:
Re: Announcing Perl 7
Message ID:
4a17be35-a135-c9ee-fd13-7a5c78bf7b36@gmail.com

On 6/26/20 9:07 PM, Joseph Brenner wrote:
> [...]
>
> I hear what Sawyer X is saying about how a unicode default would
> break lots of things, but that's indeed the argument against
> breaking backwards compatibility.  Someone who objects to this
> doesn't deserve to be classified as the equivalent of an annoying
> conference attendee that harasses people.


I'm working on a new thread in response to address the major points and 
recap on what our options are for moving forward, but I wanted to 
respond to this because I think it really matters.


I'm sorry you perceived my talk as if I had "classified" someone "who 
objects" to breaking compatibility as "an annoying conference attendee 
that harasses people." You misunderstood my point.


The point I was trying to make, which you don't need to agree with 
whatsoever, was that some people put a strain on a system. The strain 
might be worthwhile if the outcome from these people helps you meet your 
overall goal.


I presented situations with goals and personas that play on the curves 
of putting strain on a system and helping or not helping meet the goal.


There are lot of things that are different about these personas and the 
situations. In particular, someone who is looking to prevent a single 
change in Perl (even for eternity) is far - very far - from being the 
same as a person who harasses newcomers at conferences. If this is how 
you saw it, you profoundly misunderstood my comments. (I should note 
that some of the people who seek to keep Perl as static as possible are 
amazing people - personally and professionally - and I admire them as 
much as I disagree with them.)


Beyond this correction I needed to make, I want to clarify that the way 
you presented my position of people who are putting a strain on the 
system as those who simply care about backward compatibility is also 
incorrect and unhelpful to the discussion. You've expressed my position 
in a more extreme manner and it makes it very difficult to discuss "what 
is a fair strain on the system" when that point is presented as "anyone 
who puts *any* strain on the system."


The question is not whether we should aspire to retain or remove 
backward compatibility. We definitely want backward compatibility - and 
my record so far has shown this. The question is, to which degree do we 
want to retain it, and at which cost? What is the cost we accept? And if 
we want to change it, how do we mitigate it, which is what I feel most 
of the comments here - worded strongly or not - had been aspiring to 
highlight.


So far - and this is paramount for us to understand and deal with 
(because it's uncomfortable for most of us, myself included) - we never 
truly had this conversation. We never set the bar of "acceptable cost" 
except "if it's profoundly in the way of a feature, then maybe we'll 
rethink something." We never talked about the cost of the language and 
user-base deteriorating. The last time we've done this was Perl 6.


>
> [...]
>
> On 6/26/20, Karen Etheridge <perl@froods.org> wrote:
>> On Fri, Jun 26, 2020 at 9:04 AM Dave Mitchell <davem@iabyn.com> wrote:
>>
>>> My understanding was that, by default, perl7 will enable many of the
>>> optional features available via 'use feature X' and/or 'use v5.32.0',
>>> plus possibly some other stuff.
>>>
>>> I think that this will break a *lot* of existing code and CPAN modules.
>>> Which is at the heart of my objection.
>>>
>> I am greatly concerned about this as well.
>>
>> One thing that could help (and I have asked for this in the past;
>> unfortunately I have lacked the tuits to do it myself) is to compile
>> variants of perl with these pragmas forcibly turned on, and smoke all of
>> cpan with it to see the outcome.  As a cpan author and janitor, I would
>> certainly appreciate being able to see which distributions within my
>> control are affected by certain pragma or feature options, so that I can
>> proactively move to make appropriate fixes.  There may also be some
>> surprising findings from this exercise that would help inform us which
>> pragmas and features should be enabled or not enabled.  Core and dual-life
>> modules would also no doubt be affected, and they MUST all be fixed for
>> whatever default feature set is decided upon.
>>
>> This doesn't tell us anything about the darkpan, of course, but it would at
>> least give the growing list of keen-to-see-p7-happen volunteers something
>> to set their attention on in the short term. (I see the Pull Request Club
>> is enjoying a revival thanks to the TPC too!)
>>
>> --
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to doom+unsubscribe@kzsu.stanford.edu.
>>

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