> Perl 7 there was a mutiny by jealous and bitter collaborators
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.
Perl has a fast, powerful well-integrated regular expression engine, with full unicode support.
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).
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...
I think quite a few people are confused by the line about it becoming Perl 7 "sometime in the future". I think it is unlikely that that is the distant future, myself. I think the main hang-up is they'd like to get the new built-in object system (Corinna) working.
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.
> It should be easy to always stay on the latest language version
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.
> Perl devs would be in a better situation with a "fiasco" like that.
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.
> the Editions system lets people keep older syntax in source code
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.
"... but wherever I interfaced with people writing/maintaining Perl code, it was the most hastily thrown together crap"
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.
Well, Larry Wall's latest project was called "Perl 6" but has
been renamed "Raku"-- in belated recognition that it really
is a new language, and Perl is going to continue being Perl.
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.
Well, there's certainly a deprecation cycle in play, and some things may be on their way out that I would rather see kept around (e.g. they seem to have given up on getting the case statement-- given/when-- working: it's tough to do it right without built-in types), but seriously you seem to be behind-the-times on how the project is being managed. If they implement a version 7.0 scheme again, I guarantee they'll do it without breakage: you'll need to say "use v7;" to turn it on.
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.
"But unfortunately, some Perl devs in recent years keep thinking that what they need to do is break stuff to 'modernize'. They keep eyeing goals like turning `strict` on by default, and eliminating lesser-used features ..."
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.
Don't know exactly who you mean, but while sawyer x has stepped down recently, the dev team seems to be in good shape-- they've adopted the steering committee idea, and are using an informal RFC process to make decisions about new features.
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.