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