Grinnz

First, opting in to an experimental feature could be a one-liner, “use experimental feature ‘try’” or similar. There’s no point in punishing your valuable beta testers beyond that with a second line that’s entirely redundant with the first one.

It is. "use experimental 'try';" works already.

The larger problem is the versions. This basically requires someone to update their script headers all the time if they want to keep getting new features.

This is intentional. The largest strength of Perl is that, barring significant security-type issues, a script written in 1995 will still run with the version of Perl you've installed. If you write a script with "use v5.36", you would change that version only if you intend to modernize the script with features from a newer version, and determine that such features don't break the script. This is harder to determine for some features than others, for example applying the 'unicode_strings' feature to an existing script written without it is rather perilous.

That it would be maintained is all that really mattered to me, and there's no doubt in my mind that it would be.

Nor mine, but because I know that Perl 7 would die as most of the maintainers stayed working on Perl 5. Or the worst case: too many leave Perl entirely to maintain either fork. Perhaps some corporations would take up the funding, but it is not a simple piece of software you can throw new developers at and expect progress; it's an enormous C program built on thousands of macros and decades of history, as anyone who has tried writing XS code probably sees in their nightmares.

As soon as you make breaking changes,

I am referring specifically to doing it without breaking changes, as is the current plan, and the only option at this juncture.

You were reading between the lines, and the initial announcement was writing between them. But like I said, it is not feasible to maintain a LTS Perl 5 next to a fork of the interpreter. The actual proposal was only even to maintain Perl 5 for a few years before sunsetting it. CPAN would not have been compatible with Perl 7, it would require a separate ecosystem of code and installed libraries. The ideas sound nice but I don't think a lot of people would have been happy with how the details would have worked out. Most of the problems you're talking about are more a deficiency of perception and tooling, and these can be addressed without such drastic measures.

The original proposal for Perl 7 was good at grabbing attention, but not good at being something that could reasonably be accomplished by the current set of core developers - it would require either maintenance of two forks of the language (not feasible), or sunsetting of Perl 5 (risking it all on unlikely adoption and migration to the new fork, and likely losing several volunteer developers).

The current status is, roughly, planning for Perl 7 to be a compatible release with good features, and waiting until such a featureset is ready. See https://perl7faq.grinnz.com

Sinking to their level doesn't move anyone forward.

For the record, shitting on other languages does not represent the values of Libera #perl. Though I personally would not use python or PHP, use whatever gets the job done.

The CPAN upload and the commit message are two separate incidents, but to your point, things can be removed from BackPAN through some effort, and efforts are being made.

Only the person who uploaded a distribution can schedule it for deletion, and yes, anyone could do this with currently-indexed versions of their modules. Relying foremost on the goodwill of authors rather than the intervention of PAUSE overlords is a feature of CPAN, not a bug.

I'm not sure what you tried with ADOPTME, but transferring first-come permissions to ADOPTME would remove your ability to maintain them and allow anyone to adopt the permissions. Permissions for future uploads are a rather separate concern from the currently indexed latest version of the module that dependency chains rely on. The index does not include distributions on BackPAN, so such distributions are only available via manual intervention.

The article has now been updated to correctly indicate that other than Sawyer, these events are specifically regarding TPF and not the community as a whole. Thanks to the author for clarifying things.

My comment saying this on the article has now been downvoted enough to hide it. I guess they don't care about the article making actively false statements like "The Perl community is in a shambles due to disputes concerning its (nonexistent) Code of Conduct, its (inconsistent) enforcement of community standards, and an inability to agree on what constitutes toxicity or a proper response to it." and "At least five extremely senior Perl community members have resigned from their positions and/or withdrawn from working on Perl itself"

While you're correct, what they "left" is actually a non-programming legal foundation (other than Sawyer X), and so the commenter is actually correct that this ultimately does not have the impact on the Perl community that the article suggests.

There doesn't, and most of this doesn't actually affect the Perl community or development at large.

This article seems to be highly misinformed.

The Perl Foundation is not The Perl Community. Sebastian Riedel and Curtis Poe are still very much involved in the community and development of Perl. Elizabeth Mattijsen and Samantha McVey have not been involved in the Perl community for quite some time. Mattijsen is heavily involved in the Raku development and community, and likewise remains so after this resignation from TPF.

Sawyer X resigned from the Perl Steering Council, not TPF, and as such is the only one here that actually was related to the development of Perl. Regardless, Perl development continues apace under the newly redesigned governance described at https://perldoc.perl.org/perlgov, which has nothing to do with TPF.

Some hints (root is rasengan):

<root> jane_doe: hint the freenode network is its own sovereign state

https://freenode.net/news/taking-irc-further#canceling-cance...

More context: they are in the (slow) process of shutting down servers one at a time and bringing them up running InspIRCd with new Anope services, with none of the old channel or nick registrations.

Curious what makes you think Python will be less susceptible to this, after the whole 2to3 debacle?

I'll note that Perl just went through a year or so of painful argument to rediscover that "Perl should stay Perl", so I'd be more confident in that.

Perl

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.

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.

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.

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.

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

There is an adoption process for truly inactive maintainers: http://neilb.org/2013/07/24/adopt-a-module.html - you can also often get somewhere by just asking the current maintainer nicely by email. The timeliness of the process in the event of a non-repsonsive maintainer depends on luck and how much depends on the module. In the end it doesn't matter if a group or a person adopts it - someone still has to decide to do the work.

It's not my understanding that the "Perl 7" idea suddenly gives license to be backwards incompatible. Instead, features that have been made available and gated in previous releases can be made default in a new major version.

This is planned.

Perl (5) is array-of-codepoint based, at the logical level. Those codepoints might be internally stored as their encoded-to-UTF-8-bytes, or they might not, but this does not affect the usage of the string.

Many don't really understand the string model (because many don't really understand character encoding) but it comes down to: all input and output is going to be bytes, which by default is stored as the codepoints sharing the ordinals of those bytes, and there are several mechanisms by which you can manually or automatically decode/encode those byte ordinals to the represented characters; for most text processing, you do this on STDIN and STDOUT.

As a Perl programmer, this is basically a post I might have written (aside from knowing it's not dominant anymore :) One more really cool aspect is the first class Unicode support, which Perl can do but you have to work at it.

<> is actually <ARGV>. And actually the least cryptic spelling IMO is "readline(*ARGV)" or just bare readline, which still compiles to the same opcodes. Sure, <> is more common, but it's easier to find what readline and ARGV mean.

File::Slurper is just as immediately obvious, and happens to not be fundamentally misdesigned :) Path::Tiny is also great.

raku.org is no longer available because it is controlled by the Raku project.