doomvox
Look, I hate to harsh on Sawyer X-- he's done a bunch of good stuff for perl over the years, and I hope to see him around again-- but his Perl 7 push was just a mess. He was getting frustrated about things, and tried to plan and push through some big changes before anyone could complain, but he wasn't really that clear on what the big changes were supposed to be-- he left a couple of weeks to figure it out after that big announcement, and even the inner cabal he had talked to about this stuff first seemed more than a little surprised.
One of the major things we got out of all this is it made it clear we needed some work on improved processes and transparency and such, and that's actually happened. There's a steering committee that makes a point of publishing its minutes, and an RFC process to talk over proposed changes. Some of these changes are in fact actually happening, and a number of them are discussed in this v5.36 annoucement (e.g. subroutine signatures are no longer experimental).
This actually seems like a really bright crew in charge, and they're making very sane decisions.
There's really no reason to think that there's some great benefit to breakage-on-upgrade: its a solution in search of a problem.
In general, Perl tends to be much faster than the competing scripting languages (which is why you never see people talk about benchmark numbers, they'd give you the wrong answer).
Perl has some decent CPAN modules for handling multi-process applications-- it is true that it's very weak for threaded applications.
(Raku on the other hand has some extremly convenient CAP features in general.)
Yes, most of them relatively minor though, which is why the OP has never stumbled across one.
(I found one once-- it turned out one coder had invented his own hash slice syntax. It wasn't supposed to work, but it did, until a particular upgrade...).
In general, Perl has been traditionally committed to backwards compatibility, but not fanatically so-- there is a deprecation cycle that can be used to remove the more problematic things.
Agree completely. Larry Wall is pretty brilliant, but he shouldn't be doing graphics design.
Actually, I tend to dislike cutsey-poo cartoon icons, in general. If you want to pick an animal totem, there are plenty of public domain photos of actual animals courtesy of the NSF and such...
If you're a "move fast and break things" kind-of guy, watching the perl devs in action will annoy you, because they're committed to not breaking things, and if they have to move slow to avoid it, they will.
On the other hand, if you want to be sloppy with your own perl code, or work with CPAN modules that move faster, that's up to you.
With perl you can upgrade your language version whenever you like, and do it reasonably safely, because there's a lot of emphasis on backwards compatibility.
Perl may actually have a "always gimme the latest features" option, but I don't know what it is, because things like that aren't really that popular in the perl world-- we want old code to keep working the way it always has.
Well, the hang-up in the roll out of "Perl 6" (now, Raku) gave people ammunition to shout about how "Perl is dead", but the central trouble was a lot of people wanted to spread that word. Myself, I think the success of a weirdo outsider language was making some insiders very upset, and they were fighting back any way they could.
Supporting older, variant behavior isn't really causing problems for the devs, from what I hear, when it does they go after it with the deprecation cycle.
Perl 'features' are lexically scoped, and could be applied in a finer-grained style, if you like. Shutting something off locally is done pretty commonly (e.g. to silence an ignorable warning).
The Perl devs have a deprecation cycle to remove mis-features, even if that breaks backwards compatibility. They don't, as far as I know, make much effort to line that up with major version changes[1], it's more a matter of making sure there's a long period of warning.
[1] The difficulty of course, was that for a long time the language now known as Raku was squatting on the next major version, "6", hence the need to jump to "7" to avoid confusion with Raku.
Dated pop-culture references in something that's ~25 years old is hardly surprising.
The badly written stuff needs more "maintenance", and the people who need to work on it are more likely to complain (and I think you're stuck on confirmation bias).
In the late-90s, the early web gold rush was on, and a lot of amateurs started writing perl in a hurry as their first language. The fact that they could do anything at all is actually pretty amazing, and I'd say that's a point in perl's favor.
The main reason to learn Raku at present is simply that it's profoundly different from most other things out there-- there's no particular "killer app" that's emerged for it, but it's unusual enough that this might happen yet (no one expected Perl would be critical for "Web 1.0" and the Human Genome Project...).
Some Raku features:
(1) it's numeric types include true rational numbers, so there's less chance of being tripped up by floating point approximations (e.g. 2/3 is really 2/3, and if you multiply by 3 later you get precisely 2). It also does big integers by default: you're less likely to have overflow problems.
(2) Raku's regular expressions have been redesigned from scratch, and it ships with expanded capabilities to compose them into larger structures called "grammars": Raku is a uniquely powerful tool for writing special-purpose parsers, ala domain-specific languages. (Note: this is how Raku parses itself-- it's not implemented in the usual lex and yacc style.)
(3) Extremly convenient features for handling CAP (concurrency, asynchrony, parallelism), possibly the easiest to use of any language.
As for Perl (meaning the original, Perl 5), it's vastly superior to traditional bash scripting because all the components were brought into one process where they could be made more consistent and talk to each other easily.
How Perl compares to Python is a little difficult for me to answer: I prefer Perl, but I could be biased on this one, and there's no question Python has quite a bit of momentum at present in a number of areas.
I have a feeling you're reading Richardo Signes wrong, by the way-- he likes to play up what a negative kind-of-guy he is, and makes critical remarks about the state-of-perl in public that some people take a little too seriously. Perl-haters gotta hate, and they really loved to link to his talk with the title about how perl is an "Ongoing Disaster" or some such.
There was some talk about that a few years back, but those ideas have largely been abandoned. They've also adopted the "steering committee" approach, and they have something like a formal RFC proceedure to talk over new proposals-- in general the project is in very good shape. And backwards compatibility is still the rule, unlike a lot of other projects out there.
"But it turns out that strong typing does not eliminate the need for careful testing. And I have found in my work that the sorts of errors that strong type checking finds are not the errors I worry about."