Hacker News new | past | comments | ask | show | jobs | submit login
I am stepping down from Perl Steering Council and Core (topicbox.com)
141 points by jnotberg 26 days ago | hide | past | favorite | 173 comments



Perl has had a really rough time. When I was in my Bioinformatics Grad program, back in 2016 I briefly considered learning Perl b/c there was/is still a lot of tooling written in Perl. I was able to get by and at this point I will probably never learn it for my job. I'm not poopooing the language. I think language design is hard, and it sucks that once a language reaches 1.0 it's shackled by decisions that will come to haunt it decades later.

It really sucks that popular open source projects have to face so much abuse on a daily basis. Sometimes I wonder if this is a product of the internet or programmers in general. I've had plenty of bad experience on stack overflow, and various other programming forums even just asking questions, so I can only imagine what it's like being a maintainer of something people actually use.

If I ever create something popular that people use, I'd probably move it to gnu savannah, or use svn or mercurial, to make it harder to contribute and weed out the haters. But I've never made anything useful enough to warrant that.


My pet hypothesis is that, if your social life is primarily mediated through a computer, you're effectively performing a version of the Harlow's rhesus monkey experiments on yourself.

https://en.wikipedia.org/wiki/Harry_Harlow

My much more charitable hypothesis is that it's just easier to take your frustrations with life in general out on the Internet, because it's so easy - especially when you're experiencing stress or anxiety - to lose track of the full reality of the fact that there's another real live person at the other end of the tube. Basically, the Internet encourages us to behave solipsistically.


I love this idea. I have a pet idea too that's a little different. You know how dogs get fence anxiety which causing them to viciously bark or attack the fence when they see another dog or strange person? Oftentimes, if you open the fence and let them greet the dog or person, they are completely at ease. They just don't like being unable to assess the situation.

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.


Agreed. That's actually one of the reasons why I hate driving, and prefer to use public transit whenever possible. I can feel the experience of being in a car making me less empathetic.


Yeah, A lot of people say I've very friendly and I do my best to be a great human bean, but I definitely road rage from time to time and it makes me sad. Self-driving cars and more public transit can't come any sooner!


Word-less xkcd about this: https://xkcd.com/438/


At least some if not most of these people are doing exactly same thing to people they meant normally. They do it to juniors, colleagues, partners, siblings. But in real life it is easier to tell you off.

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


True story... when I was in college (2000 or so) I took a Sysadmin course at university. The course project was to implement something like the AMANDA backup system in Perl.

I found Perl insanely frustrating, and hit a deal breaker problem I just couldn't figure out in a timely fashion. I also had no interest in learning Perl as it was clear that it was on its way out even back then. Our grading was largely automated-- the assignment specified what parameters the program took, what the name of the script was to be, where to store the backup files, what format they were to be in, everything. I figured it would be unlikely a human looked at my code... so...

So I wrote one line of Perl that passed the command line parameters to a Python script, which did the actual work.

Turns out, they did review the code... I got a C which, was probably a courtesy as I was employed by the same university as a system admin.


> I think language design is hard, and it sucks that once a language reaches 1.0 it's shackled by decisions that will come to haunt it decades later.

Eh. Perl 7 is coming out, and the list of differences with Perl 5 fits in a small blog post [0]. I get that everyone got spooked by Perl 6 becoming Raku, but this is a very narrow change for a new major version. The whole point of bumping to a new major version is that you can make backward-incompatible changes. But when the new version is just a new collection of defaults seems really silly to me. Why not just add a "use new_defaults;" pragma or something that just turns on this handful of new options?

[0]: https://www.perl.com/article/announcing-perl-7/?ref=alian.in...


We haven't really gotten seriously into the discussion yet of what perl 7 will include. All that's happened so far is one person made a premature announcement of what they wanted, (parts of) the community objected, and we backed up and created a governance process.

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.


Given the state of Perl, I really think that launching a Perl 7 is crucial to its survival. Perl 5 has evolved a lot over its time, so it does make sense to draw a line in the sand with the new version number, but more critical is to simply signal that Perl is not dead, and to get people thinking about a “new version” since Perl 6 is now gone.


> Why not just add a "use new_defaults;" pragma or something that just turns on this handful of new options?

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

    use v7;
There is already plenty of precedent for doing exactly that.

    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);
One question is what quantity and quality of changes are necessary for jumping from `v5.xxx.yyy` to `v7`.

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: @_"  }
    };
It might even start using object based exceptions by default.

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


The emotional impact of stuff like this is never apparent from the outside. For many many technical decisions there is no right answer, and any decision will the be the wrong one for someone. In fact, even making a decision may be the wrong thing to do.

Making a decision in this context is real emotional work.

I strongly empathise with Sawyer X, having recently gone through a process where I had to come up with a document format and feeling the pressure to just make a decision.


I have a lot of respect for people involved in free software communities and projects. I've interacted with some maintainers in bug reports / feature requests and so far that has been extremely positive. But I haven't been part of any internet-based communities since I was a teenager. Having to argue about technical details in a non-constructive way is bad enough when you're getting paid for it - doing that when your main goal is to be a part of something useful to the world seems completely soul-crushing.

I think if I ever code something worthwhile I'll probably just vomit it into a github repo for anyone to fork as they please.


Agreed. The manner in which people treat developers is appalling to me, and definitely gives me pause before considering releasing something to the public (if I will be beholden to serve at the whim of a belittling bully / choosing beggar).


And then the very decision to step back must be weighted against the fact that there will be highly visible public commentary like this very thread, raking your passion project over the coals and questioning your experiences and motives.


I'm starting to worry that the FOSS model is sub-optimal, because it fails to take these sorts of human factors into account. We've created a social landscape that is more hospitable to project leaders who enjoy conflict, or are at least less emotionally impacted by it.


The old FOSS model is not compatible with the kind of people who are being drawn into it these days. It worked decently with thick-skinned, more-or-less autistic men who communicated relatively infrequently over email and had an understanding that they weren't beholden to anybody.

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.


The old FOSS model is not compatible with the kind of people who are being drawn into it these days. It worked decently with thick-skinned, more-or-less autistic men who communicated relatively infrequently over email and had an understanding that they weren't beholden to anybody.

I don't think it worked as well in the good old days as you think.

A lot of Perl's problems can be attributed to one of those old men, Tom Christensen. He combined technical brilliance with a flair for flaming, and was at the center of why p5p (perl 5 porters) became a hostile flame-fest. With the result that the 5.6.x series was a complete disaster. And the problems were so bad that as http://strangelyconsistent.org/blog/happy-10th-anniversary-p... describes, in 2000 Jon Orwant (editor of The Perl Journal) brought attention to it by smashing mugs against a wall.

The current spat is much less dramatic than that one was. You just know about it because it is current.

People claim that Perl's problems began with Perl 6. But in fact Perl 6 was one piece of Larry Wall's solution to a rather urgent problem. And that problem was how to separate people who wanted to create new features from people who wanted absolute backwards compatibility. Like Tom Christensen. (Who Larry Wall also told to calm down.) And ideas from Perl 6 also made their way back to Perl 5 in various ways. Yes, it became a branding problem. But if it didn't happen, Perl was set to implode on itself much more dramatically, much more quickly.


I saw a bit of that when someone on P5P mentioned that perltoot (Tom's object-oriented tutorial for perl) didn't exist anymore.

His argument for keeping it was simple. https://www.nntp.perl.org/group/perl.perl5.porters/2012/05/m...

    Wanna bet? :)
    
It came across to me as being abrasive, and a bit dismissive.

It didn't help that his photo showed up next to it in my email.


"Perl 6 was one piece of Larry Wall's solution to a rather urgent problem. And that problem was how to separate people who wanted to create new features from people who wanted absolute backwards compatibility. ... But if it didn't happen, Perl was set to implode on itself much more dramatically, much more quickly."

Care to expand on this a little, or suggest an external resource where it has already been elaborated upon?


What btilly said!


> It worked decently with thick-skinned, more-or-less autistic men who communicated relatively infrequently over email and had an understanding that they weren't beholden to anybody.

It didn't work well, but it worked, sorta--until it didn't (see: jwz and xemacs).

The difference wasn't the maintainers--the difference was the users. The "users" have gotten exponentially more numerous and steadily less competent. (I have an argument that so have the maintainers, but that's less easily argued while the drop in competence of users is horrifyingly easy to quantify.)

A lot of complaints on the old newsgroups were met with "Send a patch or shut the fuck up". Generally followed by: "Alright, here's your damn patch, asshole. Now fix it."

This moves things along in spite of the general hostility and roughly scales. But it requires that the users are somewhat on the level of the programming capability of the maintainer.

It also doesn't help in the modern world that if you are a maintainer, you are expected to be some infinite well of endless tact instead of being able to tell some dipshit with teenage social skills: "Look, I don't give one ounce of flying fuck about you and your opinion and you can fuck right off to whatever primordial ooze you just crawled out from. You are killfiled." Then you get the Twitterverse whining at you even if you aren't on Twitter.

AOL created "Eternal September."

Twitter managed to one down that and created "Eternal High School."

So, who's got dibs on "Eternal Middle School"? Twitch, maybe?

In general, while I happily released stuff as open source in the past, I wouldn't dream of releasing anything now even if you put me under duress. If I release something as open source now, I have to perceive the benefit to ME as being very high.


"Eternal Middle School" is obviously TikTok


I think it's a bit more complicated than that. Hard-to-work-with individual have been a problem in open source projects for a long time. What I think is changing is less the personalities of new contributors and more that [sub]projects controlled/significantly influenced by such personalities are getting harder and harder to route around.

It's feasible to fork a project / create an alternative if that's single-digit person-year/year of effort. There's plenty historical examples of that. If however maintaining / creating an alternative would take very significant resources, it's only going to happen if some large corporation foots the bill. Which has its own problems.


*THIS**

If ever a collection of words thrown together has outpunched its weight, it is this! Brilliant! And I will be using it often, with reference to thrower123 on ycombinator. Just. Ducking. Brilliant.


Looks like he pulled down his Twitter account recently too.

Wayback: https://webcache.googleusercontent.com/search?q=cache:3Wcvdp...


There are some zingers in here:

> Someone responded to a post of mine saying not masking is about FREEDOM and he “will not wear a mask of FEALTY” and look buddy I don’t know why you decided to make a simple hygiene item part of your big oppression cosplay but the rest of us are just out here trying to survive

I'm definitely going to start using the phrase "oppression cosplay". I haven't previously found sufficiently belittling words to describe people like this.


I don't really understand the thread. This guy X writes about the harassments and then someone replies and asks about the release versions?


Being a Perl leader means doing things like releases; that is a key purpose of the role. Try reading what the author wrote at the end, where he raises the topic of organizational continuity in light of his departure:

"I am slated to release 5.34.0 in May, and I still intend to do so unless PSC and the Core object to it. Once I cut the release, I'll remove my permissions and commit bits to GitHub, CPAN, and mailing lists."


In late stage projects there's often a cabal of passive aggressive people in charge who basically use management tactics to stay in power.

One of the tactics is to never directly respond to actual issues and ignore everything that the cabal cannot be bothered with.

Which is what incites anger in honest people in the first place and leaves them vulnerable to being cancelled.

I don't if this is the case here, but this is the reality in other projects. Whether cabal members are the actual top contributors or have any valuable ideas is left as an exercise to the reader.


pretty much the opposite happened here

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


My interpretation would be they are glad to get rid of him OR they are a completely tone-deaf group. If someone rage-quits and cites harassment, you absolutely have to take this up, even if that person won't change their mind - but to prevent it in the future.

If you are asking in the most lame tone for the next release, you basically tell them to get lost.


OR... they are being respectful of author's experience, decision , life and feelings, and will discuss public things publicly and private things privately.

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? :-/


>What should they have done instead - started a flame work on whether the authors experience was real

Mention something like "OK, this is an issue we must discuss, are you free to have a call now or later about the issue?"

Like every organization would handle it if they have some crisis management skills. To give the person who felt mobbed a voice, things like that.


Yeah, you do not need a reason and you do not owe the community a lengthy conversation about whether your emotions are valid. You're a volunteer. It's great if other people there reach out for support, but ultimately it doesn't matter if anyone else thinks their experience was real or if their response is reasonable.

Explaining your emotional response when you've been dealing with this kind of thing for an extended period of time is harmful to yourself and I don't think it's remotely fair to complain about them not doing that first. Step one is to keep yourself safe and emotionally healthy. Usually when people get to this point they need at least months before they're even comfortable discussing it privately again, this sounds like it's been going on for a while.

If the organization wants to discuss things on their own they can feel free but including the person who basically says "I'm out" and insisting that they participate if they care about it changing is harassment too, and a recipe for people who have been seriously upset to just get ignored when they refuse to enumerate every instance of behavior that bothered them and have them picked apart by strangers.


They're not asking for a release. They're trying to organise the task ownership / transition after the stepping down, which needs to be done.


A telltale sign that they're siding with the bullies or not taking this seriously.


Or they're sending their personal regards in private, while publicly discussing the publicly relevant transition matters.

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.


Yes, you're probably right.


The individual stepping down says there are no issues with either of the other two leaders for the release. I'd have to dig, but it's likely a team of three to avoid ties and a have the responsibility spread out.

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


I'm not sure what it is about the Perl community in particular that seems to trigger such vicious fights. Larry Wall is a really nice guy (and living proof that Christians can be perfectly decent and tolerant people, too), but even back in the 1990s, perl5-porters was not a really nice environment.

In 2000, there was an attempt to settle some of the worst fighting among the porters, and there are suspicions that the launch of Perl 6 aka Raku at the same conference was not unrelated.

I stopped following the community so closely soon after that, but it looked like the fighting mostly moved over to the Raku side after that, but continued unabated in vehemence.

Maybe it's all those %^&% punctuation marks that Perl programmers are already habituated to cursing?


> the fighting mostly moved over to the Raku side after that

I think the fight was mostly between people who wanted the Perl 6 project dropped, and the ones working on the Perl 6 project.

In any case, since the rename to Raku, we have seen some disagreements in the community, but these have been solved (although in one case banning from the core has been necessary, unfortunately).


I distinctly recall some rather bitter disputes WITHIN the Raku community, where debates often revealed that the maintainers of the Perl 6 VM were not talking much with the maintainers of the Perl 6 frontend (which, absent ironclad and stable specs, was not a recipe for success), and sometimes the VM maintainers were not even interested in Perl 6!


I recall things differently! The leaders of the Parrot VM and the leaders of the P6 implementation and the P6 language designers were on the phone directly every week talking through things.

Up until we weren't, but that was basically the point where the P6 language designers said they wanted to write their own VM anyway.


Well, you were there and I was not; all my impressions are secondhand. But, looking back at my grandparent comment, I worded this really poorly.

It was not whether the people were talking, but whether the components grew in convergent directions. My impression was that for extended periods they did not. Am I wrong?


My take:

1. Parrot was initially intended to be the backend for Perl 6. 2. Perl 6 didn't materialize fast enough, so Parrot started focussing on hosting other scripting languages. 3. Parrot decided to become the backend for all scripting languages. 4. Parrot became less and less targeted towards Perl 6. 5. Parrot never really became a backend for any other scripting language. 6. Parrot became decicedly a poor fit for Perl 6. 7. Jonathan decided that maybe the JVM could also be a backend, and started porting 8. Building on that experience, Jonathan decided that they could write a dedicated backend for Perl 6, which became MoarVM 9. Parrot development dwindled to effectively 0. 10. During the Great List Refactor of 2015 (about 6 months before the first release) it became clear that porting the Parrot backend would be a lot of additional work, with no apparent upside 11. Parrot support was dropped before the first official release


Parrot was always intended to support multiple languages, from Simon's original April Fools joke to Larry's dual desire to run both P6 and Perl in the same process on the same VM as well as to make CPAN available to all dynamic languages in the same process on the same VM.

That's why Dan and Guido had a bet that Parrot would run Python faster than CPython, and that's why Parrot attracted contributors like Sam Ruby.

It's definitely true that, as P6 dragged on and burned out a lot of contributors (including multiple project managers), many Parrot contributors thought that coupling Parrot's success to P6 was a mistake, but I can't see that as a change in focus because the multi-language focus was a goal from the start.

Granted, Parrot did wander in the wilderness for a while waiting for the P6 design process to proceed, and Parrot did evolve in some unfortunate directions because of that. The rest of this comment covers 2007 onwards though.

Your question about components is particularly interesting, because of what really happened.

A couple of P6 developers wrote PCT, a set of tools and libraries to make developing compilers and languages on Parrot easier. This was a good thing, and Parrot users and developers started migrating their language implementations to that toolkit.

The PCT developers refactored and revised this a couple of times, and to make that easier, eventually they took the code out of the Parrot tree and started syncing PCT into the Parrot tree on a semi-regular basis.

I was working with them weekly to fix Parrot bugs, improve Parrot performance, and add Parrot features to reduce the amount of code necessary in PCT. Thus it's difficult for me to believe that the Parrot developers were designing and implementing Parrot away from P6.

Toward the end of 2010, the P6/PCT developers said they were going to rewrite PCT to support multiple VM backends. I argued this would create a lot of churn in the language implementations actively using PCT (ironic, because the PCT developers spent a lot of time before and after this complaining bitterly that they couldn't keep up with Parrot churn) and would provide very little value for Parrot (PCT was out of tree already, and syncing in code designed explicitly to undercut Parrot seemed like a stupid idea). These discussions all took place in the public Parrot IRC planning sessions, which were logged.

I also had concerns about yet another rewrite undercutting P6, especially coming six months after the underwhelming Rakudo Star release, but it was clear which direction the winds were blowing, and that's when I stopped working on both P6 and Parrot.

Five years later, P6 had its first official release and Parrot was well buried.

I know this contradicts the official Raku hagiography, but I've gone back and read the primary sources a few times over the years as people have asked about it, and I'm confident the record backs up what I've said.


Well, you are definitely more informed about the pre-2012 period. I only really got involved from 2012 onward, so I have no first hand knowledge about that period, except maybe a few weeks in 2000 (when I was dragged in by Johan Vromans) and 2005 (when I was dragged in by Audrey).

I just know second-hand that something broke the trust between the Perl 6 and Parrot developers around the first Rakudo Star release. And that strengthened the notion that another backend for Perl 6 was needed.

> I know this contradicts the official Raku hagiography

OOC, which official hagiography are you referring to?

Also, I find the use of "hagiography" in relation to Raku a bit strange: if anything, with the rename, the last saint has basically left the building?


> I only really got involved from 2012 onward, so I have no first hand knowledge about that period, except maybe a few weeks

I'm in roughly the same boat. I too dipped in and out starting in 2000, and had been reading contemporary discussions on and off from around 2009.

I want to draw your attention to some things I know due to publicly available records, things I think shed light on what really happened.

The first thing is that Rakudo began technically shifting to a multiple backend architecture in mid 2009:

* Following Jesse Vincent's summer 2009 discussion with Patrick Michaud about Perl 6 running on JVM and .NET, NQP was rewritten in the fall of 2009 to support multiple backends.[0]

* jnthn edited his website to say his first interest in working on Perl 6 going forward was "Transforming Rakudo from a single backend compiler to one capable of targeting multiple backends".[1]

> I just know second-hand that something broke the trust between the Perl 6 and Parrot developers around the first Rakudo Star release. And that strengthened the notion that another backend for Perl 6 was needed.

As explained above, Patrick had already focused his and jnthn's efforts on a multiple backend Rakudo in mid 2009, a year before Rakudo Star.

And, as chromatic has said, and the record shows, commits to Parrot "fell off a cliff" in early 2011, about 6 months after Rakudo Star, and a year before the dates of the first commit timestamps in MoarVM's git history, in Q1 2012.

----

[0] https://www.youtube.com/watch?v=XgPh5Li3k4g#t=2m

[1] http://web.archive.org/web/20091218092004/http://jnthn.net/p...


> Weird how almost nothing Patrick talked about in that talk panned out -- no JVM backend ... no JavaScript backend

At the time of writing this comment:

js Use new nqp::time instead of nqp::time_(i|n) 20 days ago

jvm [JVM] Add op 'nativecallinvoke' 15 days ago

moar Disallow explicity specifying op write registers 8 days ago

From https://github.com/Raku/nqp/tree/master/src/vm


The first thing is that Rakudo began technically shifting to a multiple backend architecture in mid 2009

Weird how almost nothing Patrick talked about in that talk panned out -- no JVM backend, no CLR backend (the one that Jonathan talked about in that blog post too), no JavaScript backend, no Tcl, no Perl, no Ruby, no Python frontends.

In fact, it's amazing how that fourth rewrite of NQP ended up not working at all for any of the backends Patrick showed on his slide. Or at least not working yet.

the record shows, commits to Parrot "fell off a cliff" in early 2011, about 6 months after Rakudo Star

How strange that that happened just after the developer summit where I said that the NQP strategy was going to leave Parrot developers in a dead end. Imagine that -- people don't want to stick around on a project that's continually undercut by bad technical decisions.

Thanks for finally confirming what I've been saying for years.


> that the NQP strategy was going to leave Parrot developers in a dead end

If Parrot had provided all that Perl 6 needed at that time, I don't think the multiple backend strategy would have been selected. Why would one?

> where I said that the NQP strategy was going to leave Parrot developers in a dead end

To me that feels like a self-fulfilling prophecy. Also, had Parrot been able to attract other languages to a significant extent, the abandoning of Parrot by Perl 6 would not have been an issue.

Personally, I think Parrot was not able to attract other languages because:

1. it didn't provide enough benefits to account for the extra effort needed by language developers. It definitely did not for Perl 6 at the time.

2. it didn't have a core team welcoming enough to keep anybody vaguely interested in Parrot

In the end, it is always about being able to create a community in open source. Without it, a project is indeed on a dead end.


If Parrot had provided all that Perl 6 needed at that time, I don't think the multiple backend strategy would have been selected. Why would one?

Given that the multiple backend strategy only succeeded in replacing an existing backend with another backend several years later without achieving any of the interoperability goals of the JVM or CLR, I'm not even sure how to speculate on the reasoning behind that decision.

Also, had Parrot been able to attract other languages to a significant extent, the abandoning of Parrot by Perl 6 would not have been an issue.

You haven't addressed my point that NQP yanking the rug out from most other languages running on Parrot harmed Parrot. That seems like a material concern.

it didn't have a core team welcoming enough to keep anybody vaguely interested in Parrot

You haven't addressed my point that I personally spent multiple months offering to make Parrot better fit NQP/PCT for P6 and was repeatedly rebuffed.


> Given that the multiple backend strategy only succeeded in replacing an existing backend with another backend several years later without achieving any of the interoperability goals of the JVM or CLR, I'm not even sure how to speculate on the reasoning behind that decision.

Umm. It runs on MoarVM, JVM, and JavaScript. How is that not multiple backends?

If I remember correctly, the JVM port predates the existence of MoarVM.

Granted the JVM port has only ever been a second tier backend. Partially because it only supports Java's level of Unicode support.

---

> You haven't addressed my point that I personally spent multiple months offering to make Parrot better fit NQP/PCT for P6 and was repeatedly rebuffed.

Yeah, because that really wasn't the main problem.

The main problem with Parrot was that the intermediate NQP/PCT code supporting it needed a complete rewrite.

The intermediate code for supporting MoarVM, JVM, and JS are all very similar. They are also significantly different to how Parrot was handled.

There is relatively little backend specific code in Rakudo itself for the three current ones. There was a lot of backend specific code in Rakudo for Parrot. Instead the vagaries of the different backends is mainly handled by NQP.

That means that if you made Parrot work better the way Rakudo-on-NQP-on-Parrot was at the time, it would have been a wasted effort.

---

Imagine the effort you were talking about doing was like tunnelling through a mountain.

The problem is that Rakudo-on-NQP-on-Parrot was going around the mountain instead.

Sure you would have reduced the total length. The problem is that you would have to create a new tunnel in a different direction once Rakudo-on-NQP-on-Parrot instead started tunnelling straight through the mountain to meet you.

Pretty sure that's why they told you to not do that.


That means that if you made Parrot work better the way Rakudo-on-NQP-on-Parrot was at the time, it would have been a wasted effort.

Two thoughts.

First, that wasn't my plan. We were actively working on the Lorito plan to reduce the total amount of C in Parrot and eliminate the need to write C to extend Parrot, just as you suggested needed to happen in another reply.

Second, it would have been nice to sit down and come up with a plan, rather than Jonathan and Patrick deciding all of this on their own, not telling Parrot developers, and then spending years complaining that Parrot developers weren't responsive to their needs even after their antics had chased away pretty much all Parrot developers.

Granted the JVM port has only ever been a second tier backend.

Ah, so frittering away a bunch of developer time and developers helped them halfway reach a goal years later.

As predicted.


Given that the multiple backend strategy only succeeded in replacing an existing backend with another backend several years later without achieving any of the interoperability goals of the JVM or CLR, I'm not even sure how to speculate on the reasoning behind that decision.

I'd say, it turned out to be more difficult than expected?

You haven't addressed my point that NQP yanking the rug out from most other languages running on Parrot harmed Parrot. That seems like a material concern.

I guess I don't understand how NQP would be yanking the rug out from other languages, technically speaking? That it could be seen as a vote of no-confidence: well such is life in the open source world.

You haven't addressed my point that I personally spent multiple months offering to make Parrot better fit NQP/PCT for P6 and was repeatedly rebuffed.

Not having been around at that time, I don't think it is up to me to address that point. If you were rebuffed, I can only surmise that interpersonal and technical relationships had already soured enough not to trust the validity of your offer. Note: I'm not saying that the intent of your offer was questioned.


I just know second-hand that something broke the trust between the Perl 6 and Parrot developers around the first Rakudo Star release. And that strengthened the notion that another backend for Perl 6 was needed.

If I recall correctly, that's about the time Jonathan started complaining that the Parrot object model didn't work very well for P6 and wrote his own for PCT, which is still weird to me because he was the primary implementer of the Parrot object model in Parrot. (I don't remember the dates, but he also wrote an object model in C# and another in Java, which you mentioned in another comment.)

I tried for a long time to migrate the PCT object model back into Parrot, but both Jonathan and Patrick told me repeatedly it wasn't a priority, so I stopped offering.

I'm not the only person who had this experience; I remember someone else having a similar experience with Unicode support.

OOC, which official hagiography are you referring to?

The one that says "Parrot dumped P6, so the P6 developers had no choice but to write their own VM".

I was there. That's not true at all.


As a further clarification of my earlier remarks, when I was talking about Parrot developers not being interested in Perl 6 at all, I was not referring to your era, but to considerably earlier times: https://www.sidhe.org/oldblog/archives/000435.html

Different eras with different dysfunctions, and different people involved, but for some reason, always personality clashes.


That was my era too, but it's definitely true that Dan lost interest in P6 well before he stepped down, and Leo never seemed to have a specific interest in P6.


> The one that says "Parrot dumped P6, so the P6 developers had no choice but to write their own VM".

I don't think that I ever implied that. To me, in one sentence, it's more like "Parrot and Perl 6 diverged, so that Parrot was no longer a good fit for Perl 6, so the Perl 6 developers had no choice but to write their own VM"


Parrot and Perl 6 diverged

To me this reads like the "mistakes were made" phrasing used when someone wants to be technically accurate but not say anything meaningful.

Regardless of whatever Raku developers and advocates say, I, as a lead developer of Parrot, went out of my way to make it work better for P6. Patrick asked me not to do certain things and so I didn't do those things.

Maybe that was my mistake.

But it's categorically untrue that Parrot wanted to get rid of P6 or considered P6 an afterthought or wasn't willing and able to be receptive to P6's needs, and I'm disappointed that that untruth continues to persist.


Regardless of whatever Raku developers and advocates say, I, as a lead developer of Parrot, went out of my way to make it work better for P6.

May I point out that basically nobody of the then Perl 6 team (except Jonathan) is currently involved in the development of Raku? So please don't transfer your mistrust to these people: they have no beef in this.

But it's categorically untrue that Parrot wanted to get rid of P6 or considered P6 an afterthought or wasn't willing and able to be receptive to P6's needs, and I'm disappointed that that untruth continues to persist.

Well, maybe I don't have anything meaningful to say about this, as I have no firsthand experience in the matter. So the only thing I can do in this case, is trying to be technically correct.

I believe you had the best intentions towards Parrot and towards Perl 6 (which for some reason you keep mentioning as P6 in your replies). But, for whatever reason, it did not work out. We can keep discussing the past in that respect, but I'd rather work on the future instead.

If you really want to get the history straight, I'd suggest to write a book about it, similar to http://friendlyorangeglow.com which taught me a lot about the people developing the system I grew up with. Good and bad.


The MoarVM and JVM backend supporting code was, and still are, very similar.

The Parrot backend supporting code was significantly different. So much so that to properly support Rakudo on Parrot would require a rewrite of it.

There are various reasons for that, but the main takeaway was that continuing to support Parrot made everything significantly more difficult.

(Even now the JavaScript backend code is more similar to the other two than Parrot backend code ever was.)

---

Parrot made a lot of assumptions about how objects worked.

It knew simultaneously too much about how objects worked, and not enough about how objects worked. It basically assumed that the Meta object protocol would be written in C for every object type.

MoarVM doesn't know how objects work. It gets told how they work everytime it runs. (Necessary since Raku can mutate its own object system.)

---

Rakudo on Parrot was slow. If you happened to use a Unicode character in your source file it got dog-slow.

Worse yet, Unicode was an optional feature of Parrot! WTF!!

That's not good backend for a language that has excellent Unicode support.

---

Not only did the NQP intermediate code for supporting Parrot need to be rewritten from scratch. A large portion of Parrot also needed significant work.

The main idea of Parrot was that there would be integers, numbers, strings, and other. It turns out that other was really the main category. And again Parrot was opinionated about what other even was.

It was thought that if something like integer bytecode was similar to machine-code that it would be easier to optimize it.

The problem is that something as simple as calling a function involves taking a Signature object and asking it if it accepts a given Capture object. Since even just adding two values together is a function call; doing objects fast is more important than special casing integers.

MoarVM is basically the other category first and foremost.

By that I mean if you took out the special-casing of integers, numbers, and strings from Parrot. Then redesigned the PMC code to support what Rakudo really needed, you would end up with something that is very similar to MoarVM.

The reason you might take that special-casing out is that making bytecode similar to machine-code was completely and utterly pointless. At least as far as Raku is concerned.

It doesn't matter that much if integer operations are fast if you are only ever going to run one in a row.

The reason that MoarVM isn't extremely slow is that it knows enough about objects to be able to pull them apart to only run the parts that need to be run.

---

I think that Parrot as initially designed may have been a really good fit for a Perl5+, Ruby, Python, or Lua etc; but it turns out that it really wasn't a good fit for what Perl6 eventually became.

---

Let's do a hypothetical thought experiment.

Imagine if someone did all of the work to make Parrot work again the day after it was dropped. That includes rewriting the middleware and doing enough to make the PMC part usable. So then it would have continued to work over the years.

I'm fairly certain that it would today be tied for 2nd or 3rd with JVM or JavaScript. (If not 4th.)

If the Unicode support of Parrot got better and faster I think it might be more likely to tied for 2nd.

For it to beat, or even meet MoarVM for first; it would end up needing so many changes that I'm not sure that it would even resemble what it once was.

---

I would have liked for Parrot to survive and be one of the backends that Rakudo runs on.

But dropping it was the correct move.


Rakudo on Parrot was slow. If you happened to use a Unicode character in your source file it got dog-slow.

Worse yet, Unicode was an optional feature of Parrot! WTF!!

This is nonsense, and I say that as the person who spent months profiling Rakudo to figure out why it was slow.

Rakudo's parser was (maybe still is) slow because it can't optimize anything, even the <ws> token.

Adding NFG could have helped by allowing fixed-width access to normalized codepoints, but IIRC Patrick told the person who was going to implement NFG not to do it.

Seems like a pattern.


You might be right about why Unicode was slow.

In which case I was right.

> So much so that to properly support Rakudo on Parrot would require a rewrite of [the middleware].

Which also means that most of the work you would have done to Parrot would needed to be reworked again afterwards.

There was `ifdefs` all over the NQP and Rakudo codebases to work around Parrot's differences. Which was annoying and error-prone.

The `ifdefs` are now mostly in NQP. And even those tend to be constrained a bit.

---

> Rakudo's parser was (maybe still is) slow because it can't optimize anything, even the <ws> token.

That is factually incorrect. There are several known optimizations that have not been implemented yet. One of which was even in STD.

Also since Raku treats regexes as code, optimizations to regular code paths can also apply to regexes. That includes optimizations to calling methods like using the <ws> token.

The main reason that they haven't been many is that the people that are competent enough and confident enough to do that work have been busy doing other things. Both their dayjobs and other optimizations or design work.

Really as far as I know, there have been next to no attempts to optimize specifically regexes and grammars since they first got to the current feature set. Certainly not in the several years where I was looking over every commit to Rakudo.


The thing that P6 really needed was a new object system.

There were two options.

1. Create a new object system for Parrot. 2. Create a new object system and a VM around it.

Considering the object system needed is almost nothing like the one that was in Parrot, creating a new VM was probably considerably less work.

Then there is also the problem that some of the major contributors to Parrot didn't care about P6. They have said so publically. I don't think they would have taken too kindly to a completely new object system dumped on their doorsteps. (That's how they might feel about it anyway.)

---

Honestly thinking about it now, I think that if option 1 had been taken there would have been a fork of Parrot. I can almost guarantee it. And I'm not just talking about a fork of the codebase. There would have been a fork of the people behind it as well. It wouldn't have been a peaceful fork either.

I see all of the anger that you have towards what happened. I can only see it as being significantly worse and bigger if they had created a new object system for Parrot instead.

Creating a new object system, and a new VM to support it, was the correct move.

Especially considering that a number of the fundamental design decisions of Parrot which were completely unnecessary or plainly wrong.

I can only imagine the hell it would be to remove or replace any of the features.

---

You seem to be the only one still angry, still here, and still talking about it. Most of the other people who would have been angry regardless of which of those two decisions were made have either gone, or are quiet.

If the Parrot object system was replaced instead, a number of those people would still be angry, and still be here, and be loud. They would just be angry for different reasons.

Instead what happened is they got angry, but mostly drifted away with Parrot.

Come to think about it; things seemed to have gotten quieter after that event. Even though progress started going faster.

---

I would have preferred if they (you) didn't get angry about it. I would have very much preferred if there wasn't a reason to get angry.

The thing is that there would be some number of people would have gotten angry regardless. It's only a matter of who, and for what.

In the reality where Parrot got the new object system instead, I strongly suspect that one of the people who got angry would include jnthn. Since he is responsible for a lot of the progress in recent years, I think I prefer this reality.

I mean I miss the people from back then, but I think problems were piling up, and it was coming to a head at some point.


One more nail into Perl's coffin.


I think the biggest nail has a name, Python.


Python almost managed to blow itself up over the move to 3, though, in a very similar manner to the 5-6 transition for Perl. It was only through a lot of hard work that disaster was averted.


The transition was super painful and took nearly a decade. Some Linux distros defaulted to 2, some 3, some cleanly mapped to python2 and python3 and some just left "python" running some arbitrary default. It was a serious mess.

The worst part is that to an end user the differences were so minor. I'm sure under the hood and as a whole there are big differences between 2 and 3, but for most of us it was really minor stuff like "print x" vs "print(x)"


Perl 6 was what killed it by sucking the life out of the real, working, actual Perl.


Perl 6 has been recognized as its own thing, now -- that's all over. The perl we all know and love is quite alright, and holding its own.


Perl 6 was allegedly imminent enough in 2007/2008 that I was considering using it for a new project at that time before determining that it wasn't quite there yet. It wasn't until 2019 that Perl 6 officially became Raku and even later that Perl 7 was announced. A lost decade in the development of a language is pretty bad (although not as bad as the lost 25 years for LaTeX3, which has had the advantage of not having any serious competitors).


That only happened after a decade of everyone being told Perl 6 was the next version, and people gave up and stopped paying attention. Since no one is paying attention anymore, recent changes to the plans or names have simply not been noticed by most people, so you need a full-on marketing campaign to get most people to become even aware of Raku. Announcing Perl 7 seems like it would be a good way to do that.


Yes its fixed now, but the perl6 debacle was allowed to persist for years. The damage this naming screwup had on both perl5 and raku is massive.


But what he said is true. With all the focus on Perl 6, Perl 5 stagnated for nearly 20, with barely any improvements. Other languages came along and displaced Perl for many jobs.

No, Perl won't disappear any time soon. It still excels at a few things. And like Fortran and COBOL, Perl will also have a long life as a legacy language.


It wasn't even stagnant for a full 10 years, let alone 20.

Perl 5.8 was released in 2002

Perl 5.10 was released in 2007

It has had a release every year since 5.12 in 2010.

The latest was 5.32 on 2020-Jun-20. (Less than a year ago.)

The book Modern Perl was first released in 2010. It's 4th edition was released in 2015.

---

Even if you ignored 5.10, there is only 8 years from 5.8 to 5.12 when the yearly releases started happening.

I really don't understand how you managed to get 20 years from any of those dates.


... why do you think Perl 5 stagnated for 20 years ?

There were like 10% performance improvements at each new release, a lot of work was done in modules which was by design Perl 5 having a small core and a lot of the features being implemented in modules ...

What feature exists in other languages (except for CPU types: int, float, char etc.) and does not exist in Perl 5 ?


I like that.

But not that:

> This is just one example in a chain of continuous bullying and hostility I've been receiving in recent years, especially in the last year, at the hands of Perl community members

It's still a horror show, and it's getting worse and worse. This person was the perl5 lead, without particular technical nor management abilities. But getting harassed by saying "removing cruft", from the people being reponsible for the cruft is why everybody with the abilities to manage this cruft already left, and only the people who cannot see the cruft remain.


Are there any public examples of the alleged bullying?

Sawyer X said it was over admitting to "cruft" in the project, yet the only references to the word "cruft" that I can find are in his resignation email. Perhaps it occurred in another forum.


From what I just learned about sea lioning, it seems you arr doing it :)


If you enlarge the definition of sea lioning to include the GP's question, you've basically made it impossible/unreasonable to ever ask questions. I can't think of a worse thing to do in our current culture of outrage and jumping to assumptions. I'll take risking sea lioning any day over making assumptions and accepting information at face value - even if it's from experts.


I think the difference is that he's directing his question to us, and not to the person in question?

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.


Asking people to substantiate their claims on HN is not "sea-lioning," it's like the whole point of the site. Most of us come here for educational discussion.

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.


Genuinely curious: isn’t there a difference between sea-lioning (haranguing the person with questions that do not move the conversation forward) and asking for clarification on a point in order to engage with them in good faith? If so it’s hard to make that discernment from a single comment.


Yes I think there is based on intent of the question, whether it actually is just a clarification or an attempt to lead the conversation into a debate. That being said though, I feel like calling any disagreement Sea-Lioning might become the new way for people to dismiss any arguments against their opinions/ideas without actually having to provide valid thought behind their opinion/idea.


There is, but people have started using it as a catch-all defense so the conversation changes from whatever was initially said, to "stop harrassing me". It's the same tactics game developers use when they do something blatantly scummy, then start talking about how they're receiving death threats over what they did, that way they're seen as the victim.


> just because you don't see it as bullying - and bullies rarely see it that way - it doesn't mean it isn't bullying

I disagree with this claim, which seems indicative of the current moment in (U.S.) culture. There has to be some kind of cohesive, functional system of standards (or rules or basic shared definitions) for all of us to be able to communicate and work together. It would be a very dysfunctional world if everything were entirely subjective, particularly definitions of "good" and "bad" behavior. At some point we have be able to distinguish our feelings from their causes and be able to evaluate the causes against a standard of behavior (when the causes are other people or our selves).


I think the two claims are orthogonal but broadly compatible:

- The speaker/bully frequently finds an internal narrative/justification and does not believe they are bullying / inappropriate, individually or in aggregate. "I am just asking" "it's a perfectly reasonable thing to say" "they should have thicker skin" etc.

- This is not necessarily incompatible with the notion of having a understood and even agreed/public standard that all communication participants can agree to and conform (though THAT is a WHOOOOLE other can of worms these days, particularly in open source, particularly on these forums; it's a complex, not easily-solvable issue, people have different perspectives and priorities, and it turns out people are trickier than computers :).


See also posts on intent vs impact: https://www.google.com/search?hl=en&q=intent%20vs%20impatct Impact matters.


Aw, come on, dude. Why you gotta be all in his face for this?

You write that "it would be a very dysfunctional world if everything were entirely subjective." The author's claim states that bullying is not a subjective thing defined by the perceptions of the bully.

See? If you just put in half an ounce of effort to minimize conflict, you're agreeing with each other! Try it sometime!


Can you please not be snarky on HN and please generally stop posting in the flamewar style?

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.


dang, you have offended me, and I am thus unrepentant. I am offended because I've witnessed a lot of abuse in my life, and now I see you throwing the book at me minor style-guide violations (like all caps) as a means to defend bullies and their bullying.

I understand that you have many of the same issues to deal with, in terms of thankless moderation. You don't need people harassing you about your decisions on a day to day basis either! But this is important to me, and I think it is important that you are informed that you are being a bully supporting bullies.

As for myself, I'd much, much rather have you ban me from this site forever, rather than apologize in the slightest for any word choice that I have used here today; all of my words are in earnest and snarkless. Please consider this, likewise, an earnest invitation for you to use your discretion in the matter, if you believe it will improve the site. It's only 9538 karma, not that much in the scheme of things.

I would add that if you really want really consistent applications of style-guide things like all caps — and not, say, some tool where you can use style deviations a tool to throw at people when they annoy you — please consider writing a linter for comments offering suggestions to this effect before they are posted.


I guess "if you just put in half an ounce of effort [...] try it sometime" seemed snarky to me, and still does. But if you say you didn't mean it that way, I believe you.

The main point, though, is that you gave another user's comment an unfair interpretation and then went after them repeatedly (and frankly aggressively) for it. That's not "word choice", let alone spelling. That's about how we treat each other in the community. I'm sorry for having distracted from that by bringing up the allcaps rule, but to my eye (ear?) it did add to the aggressive quality of https://news.ycombinator.com/item?id=26780092.


It’s not just ‘snarky’, it’s outright patronizing, and intentionally so.


Your comment made me think about some interesting aspects of moderation, which I'll post in case anyone else finds them interesting. (None of this is about the GP comment—I'm just speaking generally.)

Even if your claim is true, it generally works better to lay out a weak moderation case rather than to make the strongest one.

Also, the stronger the case you mount, the higher the odds that you've misinterpreted someone.

Those are two separate issues, btw. The first is about effectiveness, the second is about risk. Taking on higher risk for lower effectiveness is a bad trade, so I try not to do that.

Intention is notoriously difficult to assess, especially online. If you make claims about someone's intention, they will usually say "that wasn't my intention". That just distracts from what was concretely wrong about a comment. Moreover, the community—which is the jury—is less likely to support claims about intention than specific things one can point to in a post. So again, it makes moderation less effective while putting it in a riskier position—another bad trade!


thank you for sharing this, it's very interesting to read.


> Why you gotta be all in his face for this?

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.


> How am I "in his face"?

Because this poor guy's telling us, "I can't take this anymore," that his volunteering experience was so damn combative and miserable that he quit, and he just wants peace..

And now here you are saying "yeah? well what STANDARDS does he propose by which we can evaluate the VALIDITY OF THE BULLYING?!?" and ... like, come on. It's combative, it's insensitive, and it's an altogether inappropriate demand — you don't get to expect a treatise in the "bullying was too bad, so I quit" letter, even by way of hyperlink.

In short, by embodying the problem that made him quit and applying that problem to his quitting.


Standards can be fluid, though. We don't have to live in a world where "one size fits all", and those who aren't wired for compatibility with the current society have to suffer.

Everything is subjective, at some level, no matter how much (or how successfully) we attempt to impart objectivity. It's seen through the lens of human psyche. Everything we witness is filtered by our entire life experience.

Let's presume the author is not being deceitful. They voiced an opinion about cruft in the language, and received hateful messages that pushed them to entirely leave the community. How is that not bullying? Of course a bully is going to defend their behavior, because it deflects the focus away from them and onto the person accusing them of bullying.

Bullying is a serious problem that pervades all of life. From childhood through to adulthood, bullies revel in making people miserable, either because they don't want to care about others (in which case they are a sociopath), or because they haven't been taught to care about others (in which case it could be argued that their parents were sociopaths).

The thing is, none of the arguing changes the lived experience of the bullied. The only thing that will change that is people actively making the decision to treat others better.


> Standards can be fluid, though. We don't have to live in a world where "one size fits all", and those who aren't wired for compatibility with the current society have to suffer.

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.


If we move too slowly on the topic of bullying, then people needlessly suffer.


It sounds like this person got sick of “Sea Lioning” — where you make a statement of opinion and are harangued into backing it up in detail, and if you won’t (or you do, but it’s not to the sea-lioner’s taste) you’re basically called a liar, idiot, or something worse.

It’s especially annoying when you’re a subject matter expert and the people you’re arguing with are not - often they don’t even have the requisite knowledge to understand the salience of your arguments so you either have to dumb everything down (at which point you’re now arguing with some analogy) or provide a litany of background data which is time consuming and unlikely to be read or understood by the people arguing with you.


In case anyone's wondering, the name comes from this cartoon: http://wondermark.com/1k62/


For reference, the couple in that cartoon are racists.



Huh, this whole situation just reminded me of an Erich Kästner novel I read as a child ("Pünktchen und Anton"). It had interludes between some of the chapters that were written in cursive font, where the author summarizes what just happened and discusses the characters motives, the implications of their actions and sometimes alludes to personal anecdotes.

In the prologue of the book he wrote that the story is about serious topics he would like to get children to think about, and decided to add the notes for some children who aren't exactly great at that thinking part. In hindsight phrased rather directly and condescendingly (I just looked it up to double check), but I think quite fitting to the situation here, seeing the cartoon first and then reading the clarification.

It's IMO very sad if a cartoonist has to explain the rather thin symbolism because enough people "don't get it" and go directly to pointing and screaming "racist bigots".


I read the cartoon and even read the clarification:

“Since behaviors are the result of choice, I would assert that the woman’s objection to sea lions — which, if the metaphor is understood, is read as actually an objection to human beings who exhibit certain behaviors — is not analogous to a prejudice based on race, species, or other immutable characteristics.”

Sounds exactly like the sort of thing I’d expect to hear from somebody who really wanted to show me some FBI crime statistics :p


I wonder if there is a corollary to the "If everyone you meet is an asshole" maxim when it comes to injected political opinions.


The thing is that we're at a point where I can't tell if you're talking about someone who is always complaining about being accused of being racist, or the people who are always complaining about everything being racist.


"I don't think you've properly thought this through." LMAO


this errata get's a chef's kiss.


whats wrong w/ that? its art


> It sounds like this person got sick of “Sea Lioning”

It's more like some other people got sick of that guy coming up with baseless assumptions, and (more importantly) baseless assertions, in order to support his goals; and a few of them don't let that go any more.

Because that's a constant pattern for him (he's been Perl's pumpking for several years, and then part of the ruling trio since the change in the governance system caused by the aftermaths of the announcement of his Perl 7 "plan"): he comes up with a change, or a plan like the Perl 7 plan, something that on the surface seems researched and based, and then... he backpedals because he is unable to sustain his claims, or he is proven wrong by people who actually know what they are talking about (with testimonies of recognised people, data, facts forming a consensus), or it becomes clear he didn't study the consequences of his planned changes (again, other people have to put up with the work needed to study that).

And sometimes, after a consensus has emerged and he either (seemingly) caved in or played possum (after all, both are more or less fine in a real human interaction, no need to publicly acknowledge every "defeat"), he comes back with the same points which have already been disproven. For example, this time he was arguing with some invisible authority arguments. While real data, real testimony of trustable people is sitting there and say the opposite.

Since I follow Perl 5 mailing lists in the recent years, he exhibits that same behavioural pattern. He probably doesn't even do it on purpose, he probably means well, he probably thinks his propositions are well researched and all. But he doesn't learn to do better for the next time.

Also, yesterday or 2 days ago, the Steering Committee trio of which he is part decided that for Perl 7, the decision would be to side more with the majority of Perl 5 core developers (that's a manner of saying it which is very abridged, but well...), than with his original plan. So you've got to keep in mind that his burst comes after what he probably felt like a disavowal, and this might be either the real reason, or a fair part of the reasons, rather than this alleged sea-lioning.


Thanks for the accurate and considerate response. Interesting to see the comments from people with no exposure to the people or situation.


Well, in this kind of case (which happens twice a week on the whole Web), most commenters side automatically with the first person who talks, as if it was gospel, especially these days when the person poses as a victim (it is normal, the burst often happens because you feel you are a victim, because you feel other people are unfair to you). The second effect is that once they've picked a side, that side, they then generally reject contradictory statements.

Now, I don't say my version (with its shortcuts and its dead angles) represents the absolute truth (it cannot for the simple reason I do not follow all communication channels), but damn, why don't people try to understand an learn a little bit about the surroundings of a situation before jumping to conclusions? It's okay not to comment, when one doesn't have the slightest knowledge of a situation; it's also okay to wait until one gets a little bit of cross information, both about the proceedings of final straw and about the general history/context. And the picture will almost always look less black and white, thus less outrageous.


Sadly this poor behavior seems to be encouraged everywhere these days.


Oh my gosh, I have never heard this term in my life before but it explains so many of my experiences.


Do you have any evidence of that being the case?

/me barks


Yeah but it's very classical. People come in many variations: between the religious autists, the emotional ragers, the ashamed paranoids, the hiding incompetents, the coward wises, the hungry juniors, etc, we've all seen them each time we try a shy challenge of an established practice. Especially in IT where you can survive a little bit longer with absolutely no ability for politeness or compromise.

I think the guy got a bit too emotional over that, maybe because he cares too much ? At some point you have to let go: you're not alone, and you don't have enough support ? It's your fault for thinking human relationship are about truth and reality rather than exchanges of favor and networks of influence.

Let it go this time, build a support network, come back with the proposal and see who whines the loudest. No point stepping down or leaving in shame.


> you make a statement of opinion and are harangued into backing it up in detail

I really wish this attitude would disappear from the internet. If you make an assertion, you should be prepared to provide the details. Nobody is forcing anyone to make statements of "opinion" in a public forum with high visibility. If you don't want to provide support for your argument, all you have to do is not post. Ironically, you posted this on HN, where there is an expectation of doing exactly that, and for good reason.

Edit: Since this comment seems to bother lots of people, note the quotes around "opinion" and my use of the word "assertion". My problem with the parent comment is that misinformation can slip into comments that are phrased as opinions.


Please explain, in detail, why you believe there should be a high barrier to entry for expressing opinions, how doing so would lead to anything but an impoverished marketplace of ideas, and how you reconcile any of that with the fact that you yourself just published an opinion without much justification. Cite at least three peer-reviewed papers to support your position, or else be condemned as a charlatan.


> Please explain, in detail, why you believe there should be a high barrier to entry for expressing opinions

I put quotes around "opinion". For instance:

"The blub language has the worst debugging support of any language I've used."

That is absolutely an opinion. It gives the impression of an informed opinion. Someone reads that and concludes that the blub language should be avoided because debugging will be a terrible experience. Perhaps what that person was saying is that blub doesn't have GDB support and in fact that turns out to be wrong. If someone asks for elaboration, they should indeed elaborate.

In the case of my comment, I just provided details so that everything is on the table. None of the other things you've asked for are relevant to my original comment.


Sea-lioning isn't nicely asking someone to elaborate on their view or asking for more specifics.

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.


> Keep in mind the stress here is on the personal opinion - and not statement of fact.

I wouldn't have taken issue with your comment if you had stated it that way. The problem was with classifying it as wrong to challenge something simply because it's an opinion. Ridiculous objections and ridiculous requests are of course not deserving of a response, but that's not how you phrased it.

A good example is this other reply to my comment: "Please explain, in detail, why you believe there should be a high barrier to entry for expressing opinions, how doing so would lead to anything but an impoverished marketplace of ideas" That is misleading because a reader will infer that I actually said either of those things. Anyone posting something like that should be prepared to justify or withdraw the comment.


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

What you describe is the usual case, so it's a reasonable thing to assume, but if we examine reality we can make a case for concluding in this particular instance it's reversed.

S. is a newcomer, ISTR he started out with XS just a few years before. I just spot-checked the last 200 out of 500 commits, not a single one touches the core C part, it's only documentation and release maintenance. I mention these not because I think they are strong evidence for the case that he is not an expert, but easily verifiable. nwclark, pevans, davem definitely got their fingers dirty with the core of the code base, and were (2 out of 3) also previous release managers, we should consider experts and not "just skimming".

> whether or not code has "cruft" is entirely a subjective manner.

This was not was the argument was about. It was rather: one party claims the cruft is a big impediment against improvements, the other party claims the cruft is not a big deal in that regard.


None of the people directly involved (myself included) are core maintainers beyond the weakest definition of the term, and all of us (including Sawyer) were referencing the stated opinions of actual core maintainers.


Interesting idea. Unfortunately, you haven't provided any evidence or details. Can you please defend your statement that this norm will improve discourse on the internet?

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.


There's a well known principle that extraordinary claims require extraordinary evidence. It doesn't necessarily follow that non-extraordinary claims do not require extraordinary evidence (or elaboration etc.) but it's a good starting point. Venue also matters. Applying the standards of a courtroom or thesis defense to a non-controversial claim in a casual forum is not a good-faith behavior. It's an exhaustion tactic, unfairly placing the entire burden of proof on the original speaker as though the sea lion's preferred contrary position should be assumed as a default. That's why it is so reviled among people who actually value a spirited exchange of ideas.


>If you make an assertion, you should be prepared to provide the details. Nobody is forcing anyone to make statements of "opinion" in a public forum with high visibility. If you don't want to provide support for your argument, all you have to do is not post. Ironically, you posted this on HN, where there is an expectation of doing exactly that, and for good reason.

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.


That's missing the point. Sealioning doesn't mean "provide details", it's shorthand for an argumentation tactic, which enables its practitioners to argue successfully "against" a position without evidence simply by demanding evidence from someone else. Someone coming in to sealion a discussion doesn't actually want the discussion to be had on the basis of details (because if they did, they would be providing some). They want to shut the other person down without having to go through that trouble.

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


Sealioning is totally a thing. Another thing (which to my knowledge doesn't have a well-known name) is accusing someone of sealioning as a way to deflect from having said something that could really use to be supported, while refusing to support it.

"Pi is not transcendental!"

"Wow really, I'd love to see the proof of that!"

"You're just sealioning!"

I'm not making any claim about which of these two patterns is more common or a bigger problem, but both things totally exist.


I like to see sealioning as going "why? why? why? why?" (now say that with sealion sounds). They may appear to be questions, but they're not really.


I don't see this having occurred in either direction. An assertion was made, contradicting details were provided, and then it became emotional due to past interactions.


Everyone has finite time in this life.

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.


here is the full context of the event sawyer cites as the last incident of "harrassment"

https://gist.github.com/wchristian/4e1bcdb761f20985b0a5c97a4...


Did you add quotes to harassment because you are involved that conversation?

It would be proper ettiquette for you to state such, especially since you created an account only to comment on this topic


i did so because i disagree

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


so basically perl team glues stuff with handy workarounds and says that everything's fine on social medias meanwhile behind the scenes everybody knows that this is mess

and now people argue with $Leader basing on PR statements that everything's fine?

lolxd,

I mean .NET which has very good compiler engineers used something similar to that `use v7` - `#enable nullable` and I guess it worked kinda for them, it looks bad but probably is handy.

Both seems to have reasons, but pretending that everything's fine is bad imo.


not quite?

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


From the thread linked, it looks like the primary issue is that there's just too much fighting.

It's not that people disagree (although they do), it's that the disagreement means constant war: arguing about the plan's legitimacy, the insistence that he justify everything to someone, respond to them in detail (on Twitter!), read their preferred set of emails on the matter, on demand whenever the aggressor wants, in forums like Twitter not appropriate for this discussion -- and that he expects to be punished with demands for this attention, continually, and thus have no peace.

If the maintainer says "no, please, leave me alone," he will not be left alone. His legitimacy in seeking peace is denied, his motives are questioned, his plan described as nefarious, ("hatched in secret"), ill will be spoken of him behind his back, and so on.

This is an asymmetrical exchange that wears someone down over time.


No one demanded he respond to every rebuttal in detail. Every reply presented alternate evidence which stands on its own without characterization. It was an asymmetrical exchange, but because one of the people involved was an authority figure. Aside from the position, everyone involved could equally be considered a "Perl maintainer" (that is, not very much for any of us).


Upvoting as generally informative, not because it flatters the scare-quotes around the word "harassment".


I feel less informed and more confused than before I read it.

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?


There is, but I'm not aware of the specifics that led to this level of animosity. All I can say for sure is that over the past year or so, there has been arguments regarding Sawyer's initial Perl 7 plan in public and private, and mst is extremely blunt.


Definitely a non-neutral history, but also nearly a year of intense discussions that would leave even a saint feeling burnt out. The emotional reaction was unwarranted here, but quite understandable.


Why the sock puppet if it's not "real" harassment?


which sock puppet, this account?

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


Ah, I see, you're wchristian // mithaldu? I didn't initially connect the usernames; sock puppeting needn't be contained to a single site when there's discussion spanning multiple.


What a time suck.


Who writes new stuff in Pearl?


One example is PostgreSQL, it depends on Perl and writes new stuff in it.

For instance, this commit https://github.com/postgres/postgres/commit/c64d0cd5ce24a344... that implemented a minimal perfect hash solution to speed up the parser.

The actual Perl code: https://github.com/postgres/postgres/blob/master/src/tools/P...


But only because perl was chosen as the default non-C language for postgres build system stuff maybe 20 years ago...


Yes, I agree. I just thought it was a nice example on some high-quality recently written Perl code, implementing something entirely new.


It’s my preferred language for personal stuff.

(I have no idea what’s behind it, but I’m sorry to see Sawyer X leave. And there certainly is cruft in Perl.)


Legacy uses and a smattering of personal preference.

Perl was hugely productive in its day, when alternatives were either non-existent or extremely nascent (Python and Ruby) or things like C, C++, Java, or Bash. You can probably imagine how writing Perl was fun for script-y tasks when compared to doing it in those languages. So, it has a large legacy presence and isn't going anywhere.

Plus there's a few people for whom it is muscle memory, and IME muscle memory can easily beat out language niceness/appropriateness for productivity in personal things.

Disclaimer: I was born in the early 90's so I was learning long division during Perl's glory days. My perspective is mostly from working in a large Perl codebase that was born in those years and talking with the people who chose Perl for said codebase.


Our bioinformatics core did for our backend tools. Well our intern/co-worker who left a year ago did. Oddly she didn’t like Perl at first, but took a class ended up Teaching assisting then teaching it. Loved Perl. I’m ok with it. As a text parsing/manipulating language it’s very good.

Everyone has different tastes in Languages. I’m ok with that.


I do, for national infrastructure critical systems and services. Edit: it's perl, not pearl, maybe you got auto-corrected



That'd be off topic for the tread, a mistake seems more likely.


Perl is a nice tool for quickly mangling textual data. I ended up using sed/awk and Python instead for much of what used Perl for back in the day.

Today, data is often semi-structured and jq has become part of the toolbox as well.


Fastmail, apparently.


Perl experts prefer it over Python, because:

1) forward symbol references

2) moderate type checking (at both compile and run times)

3) Mojolicious.


People overestimate the contribution of all the fancy data science libraries and schemes compared to the effort of getting clean data into place where it can be picked apart.

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.


1) What is forward symbol referencing? 2) ... what type checking? You mean scalars vs arrays? 3) Mojolicious is certainly a full-fledged web framework, but there are so many just-as-good frameworks out there for other similar languages (Python/Ruby/PHP).


Wait, you mean like https://crystal-lang.org/


> Sorry, your browser does not support the technologies needed to use our web interface. Please make sure you have the latest version, and that JavaScript is enabled.

So... what's the content?


According to the Urban dictionary, "cruft" (actually "crufty") is defined as:

    Generic derogatory term for something that is hacked together, badly designed, shabby or otherwise substandard. Often used in the description of software user interfaces.
To my ears, cruft, although legitimately computer-sciency is definitely derogatory and if I was in the Perl Core team I'd feel very incensed by its deliberate use to define anything having to do with the work I'm trying to do.

I'm sorry these things come down to personal harassment and generally aggressive behavior. I'm not trying to justify the unjustifiable, but sometimes people, specially the team leader here, needs to be a little more considerate with word choice when talking about people's work. English is not my first language and many times I've realized while speaking that a certain word, just because it's used a lot, is not adequate in certain situations as it can be demeaning of others, sarcastic and disdainful in itself.


This is really close to victim blaming. Do you really think things would have been any different if the author had avoided the word "cruft" but put forth the same meaning? I don't think it would have.


Sawyer X's paradox is that he's the soldier-diplomat that walked into the Perl 5 to Perl 7 warzone to try to fight (t)his battle (Perl 7, cruftness) and at the same time defuse the conflict. He even admits to being "offensive to some" in his OP. He's a bold person, fierce in his beliefs and in his choice of words, not a victim. And so his boldness and passion has taken him to being scolded in every possible way, from personal to technical, toxic to civilized, and sometimes he fought hard, even on a personal level and finally gave up.

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


There is also a bit of context in the referenced mailing list posts, which are in response to a rationale given for Sawyer's initial Perl 7 plan - perhaps to us, repeating the argument previously used as justification for breaking code was a sore spot as well.


> > Depends on what you mean by cruft

As the one who asked that:

That wasn't even aimed at sawyer for one.

For the other it was an honest question because Perl has a LOT of cruft both in the code, in the tooling, in the docs, in the design and the syntax. As such it was important to ask which cruft the person was referring to before being able to answer.

The existence of cruft is not in any possible way in question for anyone involved. The only questions are: Which cruft are you talking about? Why do you think it's a problem? Do the people who touch said cruft daily agree it's a problem for <implementation of x> at the current point in time?

Now note also how the above compares to sawyer's central claim in his email:

> I had dared to say that people in Core recognize there is cruft in the language

And consider that such disconnects marked his communications for almost a year now.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: