I am stepping down from Perl Steering Council and Core

I see the internet or driving cars as an example of that. You don't see the human behind the computer or car, you just see the enemy and you act accordingly. I think if you had to meet or see that person face to face, you'd automatically have empathy and no longer be a dick.

They do it pretty much anyone who is not in position to set boundaries and stop them.

I certainly want perl 7 to be more than what has been so far ascribed to it, to make the major version number change truly worthwhile.

Umm. Yes exactly. The thing is that it will instead be spelled as:

    use v7;

    use v5.10;
    ## enables the use of `say` `state` etc
    # use feature qw(say state);


    use v5.12;
    ## does the same as above but also
    ## - makes `use strict` mode the default
    ## - enables 'unicode_strings' feature
    # use strict;
    # use feature qw(… unicode_strings);


    use v5.16;
    ## all of the above, plus
    # use feature  qw(… fc current_sub unicode_eval evalbytes);


    use v5.28;
    ## all of the above, plus
    # use feature qw(… bitwise);

There is also a question of what happens if you don't have a `use v_;` or equivalent statement.

(This is not an exhaustive list of questions.)

---

Personally I would think that `v7` should make the currently experimental signatures the default. It should also make the new Cor class experiment/prototype available with the `class` keyword. (Perhaps even a `method` keyword, but that is not strictly needed.)

Since both of those are currently being developed/designed, I think that `v7` should wait until then.

---

Other things that `v7` _might_ enable/change is things like the following. (Slightly edited from: https://stackoverflow.com/a/6163129/1337 ) I am not necessarily suggesting any of these, they are just possibilities.

    use utf8;
    use strict;
    use autodie;
    use warnings; 
    use warnings    qw< FATAL  utf8     >;
    use open        qw< :std  :utf8     >;
    use charnames   qw< :full >;

    use feature qw< say state switch unicode_strings
                    unicode_eval evalbytes current_sub fc
                    postderef_qq bitwise >;
    no  feature qw< indirect >;
    use IO::Handle;

    use File::Basename      qw< basename >;
    use Carp                qw< carp croak confess cluck >;
    use Encode              qw< encode decode >;
    use Unicode::Normalize  qw< NFD NFC >;

    END { close STDOUT }

    if (grep /\P{ASCII}/ => @ARGV) { 
       @ARGV = map { decode("UTF-8", $_) } @ARGV;
    }

    $0 = basename($0);  # shorter messages
    $| = 1;

    binmode(DATA, ":utf8");

    # give a full stack dump on any untrapped exceptions
    local $SIG{__DIE__} = sub {
        confess "Uncaught exception: @_" unless $^S;
    };

    # now promote run-time warnings into stack-dumped
    #   exceptions *unless* we're in an try block, in
    #   which case just cluck the stack dump instead
    local $SIG{__WARN__} = sub {
        if ($^S) { cluck   "Trapped warning: @_" } 
        else     { confess "Deadly warning: @_"  }
    };

Again, one of the questions is what quantity and quality of changes are necessary for jumping from `v5.xxx.yyy` to `v7`.

(My only real opinion is that I think that signatures and Cor-like objects should be included. So it should wait until their designs are fully hammered out. The rest can be done in stages with `use v5.xxx.0;` until then.)

Twitter and Github are like cranking the volume knob from 1 to 11, and those kinds of arguments are simultaneously very low signal, and directly activate people's fight-or-flight responses. There seems to be a lot of instances lately of people that just can't unplug from the rage-machine in a healthy way, without flipping the table and doing an Eric Cartman.

"Siding with the bullies" and holding up a release are likely unrelated.

Just like what happens all the time when people quit things that happen offline. Not everyone feels comfortable or compelled to make such a statement in front of the team.

No matter in which venue my team members bring up their personal issues and difficulties, I will discuss project/work things publicly, and reach out to them on a personal level to support and inquire privately. Even when they choose to make some of their experience public, it is not necessarily my right, nor the appropriate / productive thing to do, to make it a free-for-all public debate.

I think it's the correct, professional, honorable, decent, respectful approach. What should they have done instead - started a flame work on whether the authors experience was real, decision was justified, start going into nitty gritties of each specific infarction... you know, exactly the stuff we're seeing develop in this thread - all of it indubitably further contributing to the author's stress? :-/

sawyer had decided some time ago that the p5p mailing list wasn't receptive to his ideas and moved things into secret decision making with like 2-3 others in the know, culminating in his announcing perl 7 as a complete surprise to the entire community. with only some people having been asked questions about topics related to it, without even being told that the questions were about a perl 7 plan.

this lack of communications then led to both massive amounts of criticism of the secret process (with some community members even being misrepresented by documents written by sawyer's colleagues in this) and MASSIVE amounts of technical issues being discovered directly after the announcement and people trying to educate about it. sawyer however basically went "i call the shots here", resulting in an election that upended the "pumpking" model, replacing it with a "3 person council" who still have private meetings, but now operate much more publicly

HN also doesn't follow you around. If you post here, people may ask you to back up your claims, and you are free to ignore them and/or stop visiting the site.

I think it's fair, in this day and age, to ask if there's corroborating evidence for the contents of a tweet/article.

Sea Lioning, I think, is a lot more about antagonizing/bullying a victim who is speaking up about about whatever act victimized them, while disguising your bullying as being a good-faith investigation into their claims. When it's actually in bad faith, and your intent is primarily to increase the "cost" to victims of bringing forth their complaints.

Huh? How am I "in his face"? This is Hacker News. We discuss posts. Sometimes people disagree. After having read the article, I am discussing a direct quote from it. Or do you think we should only discuss things upon which we agree?

>The author's claim states that bullying is not a subjective thing defined by the perceptions of the bully.

Where, in the article, do you see the author make this claim? To my reading, the implication by the author is that bullying is subjectively defined by the victim of bullying. The author does not point to any kind of code of conduct or standard (or lack thereof) by which the alleged bullying can be judged.

https://news.ycombinator.com/newsguidelines.html

Please note this guideline too: "Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith." I don't think there's a plausible interpretation of the GP comment as being "all in his face"—it was responding to a general question raised by the specific drama, which seems within the intended use of this site. Maybe it's a bad point, I don't know—certainly if you think it is, you're welcome to say why—just not by being snarky or by accusing another user unfairly, which I think you've done in both this comment and https://news.ycombinator.com/item?id=26780092.

Also, re that last one, please note the site guideline about not using allcaps for emphasis. It's not the most important point but it makes a significant difference to the threads.

Yes but they shouldn't change so quickly, and any changes should be carefully considered, debated and voted on (if possible). As it stands, standards are changing so quickly no one can keep up and we have chaos.

Essentially, sealioning (as understood in this context) in an attempt to suppress dissent. And that's bad, no matter what tactic is employed.

I am just asking questions.

P.S. My real opinion that this is very subtle, and it depends on what you're saying. As always, good judgment is essential. Some claims demand proof, others are more throwaway. The biggest pathology I see is where people think they should be able to say insulting things and not be called on it, as long as they don't address anyone directly.

This is not sea-lioning:

Person 1: I really think X is bad because A, B C.

Person 2: I disagree, X is fine because D, E, F.

Person 1: eh... I disagree. And I think D is problematic too.

That's merely a civil discussion.

This is sea-lioning:

Person 1: I really think X is bad because A, B, and C.

Person 2: You're wrong. X is fine. Why don't you explain why its wrong hmm?

Person 1: I just said, because A B and C....

Person 2: A B and C are irrelevant; Why don't you explain to me why X is bad. You can't do it! You don't know what you're talking about!

Person 1: I'm actually an expert in X, I've worked on it for two decades. I don't understand why you don't see A, B, and C are problematic?

Person 2: I highly doubt you know anything about X. If you can't explain why X is bad perhaps its your own limited understanding of X. All you talk about is A B and C but you don't explain why X is bad!

(Person 2 isn't providing any real counter-arguments; they are just saying Person 1 is wrong, asking for additional evidence, and then rejecting Person 1's arguments/evidence without explaining why Person 1 is wrong.)

Keep in mind the stress here is on the personal opinion - and not statement of fact. For example, whether or not code has "cruft" is entirely a subjective manner. There is no objective measure of "cruft" in code. You cannot "prove" code is crufty. However, you can put a group of engineers in a room, have them examine some code, and they can establish a consensus as to whether or not code is in fact "crufty" despite there being no formal criteria to define it as such. Generally, it means "messy and difficult to maintain". If you are a core maintainer, and your job is to interact with this code on a regular basis, you're the de-facto expert on its quality (albeit with some personal biases). If you think the code you have to work on is bad, and people don't work on that code are saying you're wrong after just skimming it, it's going to drive you insane.

We can't defend every intuition or opinion we have ever mentioned. People can disagree and carry on with the business of life.

In that spirit, you're perfectly entitled to have a differing opinion from mine and I will defend your right to disagree with me or anyone.

I disagree with your assessment.[0]

Furthermore, the underlying reasons for that disagreement are (or should be) obvious. As such, I decline to elucidate.[1]

[0] See what I did there?

[1] Why should I be required to invest time and energy in explaining myself?[2] Especially if I believe my statement (I'm including this because I'm guessing it isn't, at least for some folks) is intuitively obvious.

[2] That's not a rhetorical question.

i didn't have any other account to be able to use on hn, feel free to ask the mods

that said, yes, i am involved. sorry, i forgot my github account doesn't use my usual username

the longer story is:

last summer a plan was revealed (and hatched in secret) to change the default behavior of perl's interpreter. perl not being a language where binaries are distributed in a compiled manner, but code is and then compiled on the system, this would break a LOT OF STUFF.

9 months were spent on trying to explain this, and how versioning the language is the only way forward without causing linux distros to drop perl

part of the disagreement was "but if we can never remove cruft, then adding new features is impossible". several core c developers opined "this is not true".

now yesterday it was announced that instead of changing defaults, `use 7;` would be implemented to collapse several lines of boilerplate and make code marked such behave more friendly.

someone asked about the cruft, and the above discussion ensued

imo the primary issue appears to be that sawyer took a lot of the criticisms of the perl 7 change defaults plan personally

------

i'd like to reply, but hn thinks waiting 50 minutes ain't enough

sawyer was a manager, not a c developer of the perl core, and he replied to a thread mst started, so i disagree with your characterizations

vvvv

This whole discussion is weird. People arguing about whether cruft does or does not exist in the codebase, and all of a sudden "I have no interest in discussing anything with you". Is there some pre-existing beef here?

Whether it is worth learning both Perl and Python for the same project is questionable, but as for assembling and cleaning up data, I haven't come across anything as good.

Here's a few comments from a thread allegedly savaged from Twitter [1]:

> So no choosing which Perl runs for /usr/bin/perl7 and which Perl /usr/bin/perl or and which is /usr/bin/perl like with some other languages? Will I be able to use 7's features without 'use v7' if I do name the executable 'perl7'? Does using 'use v7'm mean keeping all the cruft?

> Depends on what you mean by cruft

> The people actually doing work on perl core don't seem to find the 'cruft' problematic and if they do we can rip out stuff after a deprecation period like normal, so unless/until somebody who knows the core code objects I consider that an imaginary problem.

> yeah, i tried to point this out below as well think it should be mentioned that the email linked is from nicholas clark, so there's 3 core maintainers who hold that the important of cruft in perl code is in doubt

As one can see, the word "cruft" had actually become central to the discussion, even used with apostrophes - a sign that it hit a nerve somewhere? Maybe a better choice of words and overall tact would have been better in managing egos left and right.

[1] https://news.ycombinator.com/item?id=26779586