It's still considered an experimental feature, just as it was in 5.38.x. Also the linked documents aren't 100% reflective of what's been implemented so far, a better URL would probably be https://perldoc.pl/perlclass.
I've been surprised. I have a coworker who has a deep industry knowledge but none of it was in Perl, he was reaching for ChatGPT a lot early on and while sometimes it wasn't how I would have written it it wasn't wrong. So I did some experiments and I asked Claude to do things like generate apps using the latest Class syntax which is only 3 years old at this point … it didn't have a problem.
Edit: well it occasionally had a problem where it would confuse things for Moose or Raku … but by and large it wasn't wrong it's just the syntax is new. I know Perl developers who have the same issues.
I'm not going to dispute the data, but I don't think it means what you're saying it does. Honestly, I think you've made the same mistake that most people make in this conversation and equating NPR to Public Radio. NPR is Public Radio, but not all Public Radio is NPR.
TL;DR: Based on the document you linked to the lions share of the money goes to _public radio stations_ in unrestricted grants to pay for their operations. Of the money that does trickle through that to program providers, NPR is only one of dozens of program producers and distributors, and NPR's own reporting on this seems to accurately portray the reality of how they are funded from independent stations.
Looking at the second link you provided theses are the expenditure programs that look related to public radio broadcasting in the us: Radio Program Fund, National program production and acquisition grants, Community service grants, and Public broadcasting interconnection system. There may be expenses in other categories but they don't appear to be directly related to public radio.
According to that document, these programs are:
Radio Program Fund represents expenses for the development and production of high-quality, new and innovative radio programs that might not otherwise be supported by the marketplace.
National program production and acquisition grants are restricted grants made to qualified public radio stations that must be used for the production, acquisition, promotion or distribution of national radio programs that are of high quality, creative and reflect society’s diversity.
Community service grants are unrestricted general operating grants made to qualified public television and radio stations.
Public broadcasting interconnection system [...] a new interconnection system to be used by both public television and radio stations to transmit and receive programming feeds [... as well as] “other technologies and services that create infrastructure and efficiencies within the public media system.
The line item breakdowns on these services for 2022 are
Radio Program fund: 7,145,925
National program production and acquisition grants: 24,579,081
Radio community service grants: 72,446,561
Public broadcasting interconnection: 2,871,313
Total: 107,042,880
So it looks like the CPB spends slightly over 107M on _public radio_ in the united states.
Note that the "National program production and acquisition grants" specifically go to qualified public radio stations. NPR isn't a public radio station, and so doesn't directly get any of that money. That money would go to a local public radio station (here's a [list](https://radiostationusa.fm/formats/public)). A station like my own WMFE then would use that grant money to purchase a radio program like All Things Considered from NPR. But they might also use that money to purchase a radio program like Marketplace from APM, or This American Life from PRX, or be used to produce it's own programs like WBUR's Here and Now. So that money _might_ go back to NPR, but it might not.
The same thing applies to the Radio community service grants, they're unrestricted grants to _stations_ so NPR _might_ get some of that money but much of it probably go to pay local expenses, like the salaries of the radio engineers who keep the towers up and running.
What about the Radio Program fund? That looks like it's pretty much targeted to NPR. Certainly not 100% of it is going to NPR's new programming. Even being generous all de-funding this will do is specifically cut programs "that might not otherwise be supported by the marketplace". I suspect most of that money goes to things like The Splendid Table, and Growing Bolder (neither are NPR shows btw). Unless you want to argue with Rupert Murdoch and Ted Turner that news isn't a marketable product?
The Public broadcasting interconnection is paid to _stations_ to make physically acquiring content easier and a deal with NPR, APM, PRI, PRX and others reduced that cost _significantly_, so that line item dropped to 2M in 2022 from 78M in 2021.
Nothing in your document I believe NPR _claims_ they get about 13% of that portion of a station's budget (based on [WMFE's 2021 Audit](https://drive.google.com/file/d/121U2UFSI8eNYUg59TnZtELEhBL-...) "program acquisition" was about 16% of their total budget so NPR seems credible here) … so about ~$12M of the CPB funding, add in a chunk of the Radio Program fund let's say 80% or ~$6M … we're still at about $18M of the $107M … plus another 1% direct funding (or is that 1% the Radio Program fund?) and we're around 20% of the total CPB "public radio" budget ends up in NPR. Since the CPB's "public radio" budget is only about 25% of the total expenses from the CPB … is 5% of the CPBs expenses considered "significant funding"?
De-funding "public radio" won't mean that Morning Edition goes off the air, it means that the farm report for Ida Grove, IA goes off the air … and the wildfire reports for Billings MT … and close to home for me it means that Brendan Byrne won't be able to keep doing Are We There Yet and reporting on the rockets that keep going up funding my local community with something _other_ than tourism.
The numbers aren't wrong, your definition of "public radio" is wrong when you assume it's just NPR.
I actually find Go harder to work with JSON with for exactly those same reasons. With Go if I want to parse JSON into something I can call methods on, the JSON has to conform to something I can build a struct around. If the JSON is complicated in anyway that doesn't line up with Go's sense of structs I'm forced to drop to map[string]interface{} (or something like it). With Perl I can parse into the hashref equivalent of map[string]interface{} and still be able to bless it and call methods on it.
This isn't to say that Perl is better or Go is better, they just have different affordances. Perl is designed for loosely structured data and that causes all kinds of problems when you want to enforce highly structured data. Go is designed to handle strictly structured data and the ramp down is hard when you don't have that.
Also mod_php was more akin to FastCGI with the limited access it gave PHP to the Apache request cycle. While mod_perl allowed you to effectively override any stage of the Apache request cycle with custom code. With mod_perl2 this was pushed to the point where I believe the Apache Foundation was running Apache for their SMTP servers running custom Perl protocol handlers.
Rowling's statement wasn't even explicitly true before the rise of transgender visibility. It excludes women who don't conform. I've lived with pre-menopausal women who didn't menstruate regularly and felt that they were "wrong" somehow because of it (some had underlying medical issues, some did not). To use Graham's analogy, even ignoring transgender issues, the orthodoxy there was privileged against the multitude of female experience.
Rowling's statement is true if your experience leads you to prioritize the orthodox. It's patently false if your experience deviates from the experiences that created it. The struggle in the conservation of orthodox values (e.g. sisterhood of women) and the visibility of heterodox experience (e.g transgender issues & the lived experience of women who's bodies don't conform to the stereotypes being used) has a lot of truth on both sides.
That's not exactly fair to Raku. A more fair critique (and keeping with the theme of this thread) is that Raku is less focused on integrating with the Unix command line than it is on tool building putting it closer to Python than Perl(5) in the spectrum of things. This was a specific design influence dating back to the first days of Perl 6, so it makes some sense.
Most of it's developers and advocates have moved on to other more popular languages is arguably true (in addition to JS/TS I see a lot of Perl devs moving to Go). I know I personally do very little Perl despite working on a team where a significant portion of the work is done in Perl that is less than 2 years old.
But that's not what you claimed, you claimed the developers and advocates were mostly retiring. And that simply doesn't appear to be true ... yet. Give it 10-20 years and I'll expect it to be very true.
I'd also say that Perl's popularity is effectively gone in the general use of the term. While some new development is actually being done in Perl, IME the only people choosing it are already Perl advocates.
Not exactly true. The current lead maintainer for Perl 5 is in his mid 30s at a guess, a large chunk of us are between that and our early 50s. This puts most of us around a decade or two out from retirement.
That said the Perl community does lack a steady stream of fresh young people ready to do impossible things because they don't know they're impossible.
While it's true in human language that idiomatic expressions are a barrier to learners, they are also a means of enhancing communication between experienced users of the language. Take Jargon for example, I've not got deep experience in functional programming, category theory, or discrete mathematics (really anything much higher than college stats), so the phrase "constrain the input domain of functions" set me scratching my head a little. I'm still not exactly sure what you meant by it.
However, it's one of those phrases that I'm sure is immediately clear to your intended audience. One who has experience and understands that monads are simply endofuctors that map between two category spaces (I think I got that right, and if I didn't the main point was illustrated anyway). As a person gains experience their language usage become much more intentional and expressive. Idiomatic language is really only this expression of experience and an effort to communicate the full context and nuance as succinctly as possible.
The best Perl developers I know understand this and what you see as praise for arcane-ness is usually in my opinion just embracing the idea that jargon and idiomatic language is inescapable, and should be just another tool in the toolbox for expressive writing.
Also Perl does some weird shit, and sometimes you gotta hack around that.
> Yet you have to know both versions of them all, and be able to recognize and understand both kinds when reading other people's code.
You have to be able to understand that if it's a two character variable of all punctuation you may need to look it up to figure out what it is. Typing `!perldoc $"` into duck duck go sent me to https://perldoc.pl/variables/$%22 ... which is roughly equivalent to `!g [docker error]` which I already do all day long.
So I wanted backspace too, but thinking about it, even within the same sentence it would damage the purpose of freewriting which is to stop editing and get words flowing out of your head and into somewhere you can be objective about it later. On a five minute run (my initial one) I found myself running up against the red words a few times as I self-edited what I wanted to say, and it helped me stop that and move forward again. I'm pretty sure I didn't break the sentence barrier those times either, but then, as you can tell, especially from this pernicious example, I'm prone to more lengthy run-on sentences — overloaded and dripping with information in a languid fashion.
There isn't one way to do it in Perl (EUMM, Module::Build, Module::Build::Tiny, Module::Install etc), we just tried to make sure that they all interoperated cleanly. And we have things like the Toolchain Summit to make an emphasis on that.