What happened to Perl 7?
For now, our plan is to continue introducing new features and to resolve all existing experimental features, so they're either dropped, or become non-experimental features (and so are included in the version bundle). The downside with this is that people often can't remember which version of Perl introduced which feature(s). At some point in the future, the PSC may decide that the set of features, taken together, represent a big enough step forward to justify a new baseline for Perl. If that happens, then the version will be bumped to 7.0.
Posted May 26, 2022 15:48 UTC (Thu)
by nas (subscriber, #17)
[Link] (12 responses)
Posted May 26, 2022 16:52 UTC (Thu)
by flussence (guest, #85566)
[Link] (10 responses)
Posted May 26, 2022 17:38 UTC (Thu)
by Smon (guest, #104795)
[Link] (6 responses)
> The downside with this is that people often can't remember which version of Perl introduced which feature(s).
Posted May 26, 2022 19:37 UTC (Thu)
by flussence (guest, #85566)
[Link] (3 responses)
Posted May 26, 2022 19:58 UTC (Thu)
by tialaramex (subscriber, #21167)
[Link] (2 responses)
"There's a list" is an answer to "How do I know?" but not to "I can't remember".
Posted May 26, 2022 21:07 UTC (Thu)
by ballombe (subscriber, #9523)
[Link]
Posted May 26, 2022 22:12 UTC (Thu)
by flussence (guest, #85566)
[Link]
Nobody asks for or is impressed by rote memorisation of trivia like this, except high school exams and whiteboard interviewers at toxic workplaces; getting annoyed at the presumption of having to do so is silly when *you don't*! If you're using a programming language then you have a computer available, here's how to get a history of syntax-affecting feature flags straight out of the computer, ergo there's nothing wrong with it. (I wish pydoc was half as thorough...)
As an aside everyone in the vicinity now knows that 1) there's a self-contained CLI doc system 2) it contains useful information that you're not expected to memorise 3) the existence of said info implies perl doesn't do Flag Days with unavoidable breaking syntax changes.
Maybe the article could've spelled everything out and saved all this, but it's honestly asking too much to expect it to - it's aimed at entrenched perl5 users waiting for rapture after the broken mugs incident, who care about the specifics of things like the forward compatibility of postfix dereferencing sigils, and they all presumably got taught how to use their tools in the far less polite environment of the 90s/00s.
Posted May 27, 2022 2:14 UTC (Fri)
by jengelh (guest, #33263)
[Link] (1 responses)
Posted May 29, 2022 23:47 UTC (Sun)
by rra (subscriber, #99804)
[Link]
Personally, I prefer use <version> to explicit use feature anyway since for documentation purposes the minimum supported version is the actually important information. (But I also don't tend to use any experimental features that are off by default.)
Posted May 26, 2022 19:55 UTC (Thu)
by tialaramex (subscriber, #21167)
[Link] (1 responses)
This means that most of Perl's codebase needn't even be aware of feature flags, only the parsing logic. In the rest of the codebase it's as if all feature flags were always enabled.
Posted May 27, 2022 0:13 UTC (Fri)
by NYKevin (subscriber, #129325)
[Link]
At which point, I suppose, the answer is "Just don't do that then." Instead, you introduce a new object that exists at runtime, and the parsing logic creates either an instance of the new object or an instance of the old object depending on which feature flag is lexically in-scope for that particular declaration. Then new code gets new semantics, and old code gets old semantics. Problems:
* If the object is first-class, then old code will expect instances of the old type, and new code will expect instances of the new type, so you probably have to expose this difference in the type system.
Posted May 26, 2022 21:24 UTC (Thu)
by nas (subscriber, #17)
[Link]
Posted May 26, 2022 17:13 UTC (Thu)
by RobertX (guest, #138591)
[Link]
Posted May 26, 2022 20:06 UTC (Thu)
by meuh (guest, #22042)
[Link] (10 responses)
Posted May 26, 2022 20:25 UTC (Thu)
by rahulsundaram (subscriber, #21946)
[Link]
Posted May 26, 2022 22:10 UTC (Thu)
by rgmoore (✭ supporter ✭, #75)
[Link] (7 responses)
The people developing Perl 6 eventually decided it was too different from Perl 5 to be considered the next version and decided to rename it Raku instead. To avoid confusion, the people who continued to develop Perl 5 have decided to skip straight to Perl 7 if they ever want to increment the version number.
Posted May 26, 2022 23:34 UTC (Thu)
by pebolle (guest, #35204)
[Link] (5 responses)
Is it too cynic to think that in the entire Perl 6 train wreck that is one of the few sensible decisions?
Posted May 27, 2022 1:29 UTC (Fri)
by felixfix (subscriber, #242)
[Link] (4 responses)
Posted May 30, 2022 16:45 UTC (Mon)
by rgmoore (✭ supporter ✭, #75)
[Link] (3 responses)
Perl 6/Raku wasn't invented by a bureaucracy, though; it was straight from the mind of Larry Wall. The big problem was second system effect. Perl had worked hard to maintain backward compatibility through Perl 5, which constrained Larry's ability to make big, incompatible changes. He threw that all out the window for the design of Perl 6/Raku, though, and just went wild with all the ideas he hadn't been able to follow through on for the previous 20 years. Some of those were good ideas- I think the extension of regexes to grammars and changing the way sigils work were long overdue- but many of them were just change for change's sake.
Posted May 31, 2022 23:07 UTC (Tue)
by bartoc (guest, #124262)
[Link]
It does mean perl6 is almost self-hosting, which is neat I guess.
Posted Jun 8, 2022 10:12 UTC (Wed)
by niner (subscriber, #26151)
[Link] (1 responses)
Posted Jun 13, 2022 21:35 UTC (Mon)
by flussence (guest, #85566)
[Link]
Posted May 27, 2022 6:09 UTC (Fri)
by bof (subscriber, #110741)
[Link]
Posted May 28, 2022 3:14 UTC (Sat)
by jahigd02 (guest, #158771)
[Link]
Posted May 26, 2022 23:27 UTC (Thu)
by pebolle (guest, #35204)
[Link]
But at least they made clear Perl 5/7 will stick to backward compatibility. It could have been much worse...
Posted May 27, 2022 9:23 UTC (Fri)
by Gladrim (subscriber, #45751)
[Link] (22 responses)
That's pretty much the opposite of what I look for in a programming language.
I want stable. I want my programs to run unchanged in 10 or 20 years time. Sure, *bugs* need fixing, but programs shouldn't need updating because the language has changed underneath them. That kind of breakage is what frameworks are for.
Posted May 27, 2022 10:12 UTC (Fri)
by jorgegv (subscriber, #60484)
[Link]
Posted May 27, 2022 12:31 UTC (Fri)
by rahulsundaram (subscriber, #21946)
[Link] (17 responses)
There is nothing at all wrong with accelerating the rate of change as long as backward compatibility is maintained and Perl developers have a good track record of doing so. I don't see the problem.
Posted May 27, 2022 13:04 UTC (Fri)
by Gladrim (subscriber, #45751)
[Link] (16 responses)
Posted May 27, 2022 15:03 UTC (Fri)
by rahulsundaram (subscriber, #21946)
[Link] (3 responses)
Other languages including C++ and Python are adding new features all the time despite being decades old. This is hardly unusual.
Posted May 27, 2022 16:39 UTC (Fri)
by Gladrim (subscriber, #45751)
[Link] (2 responses)
Posted May 27, 2022 20:30 UTC (Fri)
by rahulsundaram (subscriber, #21946)
[Link] (1 responses)
This is a bogus comparison. Car accidental are strictly harmful. Language changes can introduce substantial new widely anticipated features that are objectively an improvement to developers (I can point to any number of relatively recent C++ changes as examples here) although not universally so. If you have a preference for a more static language, just stick to an older version or continue using a language that barely changes at all, Perl may not be suitable for you. As long as backward compatibility is maintained, I still don't see a problem.
Posted May 27, 2022 21:07 UTC (Fri)
by Gladrim (subscriber, #45751)
[Link]
> If you have a preference for a more static language, just stick to an older version or continue using a language that barely changes at all, Perl may not be suitable for you.
Precisely. I think that was clear from my first comment.
Posted May 27, 2022 16:33 UTC (Fri)
by tialaramex (subscriber, #21167)
[Link] (11 responses)
There's a lot of room between stuff that's hot this week but nobody will care about a year from now [which I agree Perl has no need for], versus stuff that if you still don't have it ten years from now people will laugh at grandpa's language for old-timey computers. I don't think the people writing this essay expect to ship a new Perl feature every week, but on the other hand it gets old fast when you're teaching newcomers your language but have to caution them that the feature you added *last* year still won't really be usable *next* year because the ecosystem is so slow to adopt change, so here's a nasty hack instead.
Posted May 27, 2022 16:47 UTC (Fri)
by Gladrim (subscriber, #45751)
[Link] (10 responses)
Posted May 27, 2022 18:58 UTC (Fri)
by NYKevin (subscriber, #129325)
[Link] (7 responses)
The baseline assumption of this discussion is that we don't break backwards compatibility. If you insist on postulating that all new features break backwards compatibility, then yeah, you're going to come to the conclusion that new features are bad.
That conclusion is wrong, though.
Posted May 27, 2022 19:25 UTC (Fri)
by Gladrim (subscriber, #45751)
[Link] (6 responses)
Did I insist on postulating that all new features break ... anything? I don't think so.
Is there an increased risk of breakage if the rate of change increases? Yes. Of course.
Do I think it's where a mature, stable language should be focusing its energy? No.
YMMV
Posted May 27, 2022 23:36 UTC (Fri)
by tialaramex (subscriber, #21167)
[Link]
Maybe that's less obvious than you think it is. Once we accept that change is inevitable (which you seem to) then there's actually some reason to think we should prefer a somewhat steady tempo of change, not necessarily the minimum possible delta.
One reason is rust. Not the language, the problem. If you don't exercise freedom of motion it rusts into place without you realising. This is why TLS 1.3 is spelled SSL 0x0303 on the wire, first TLS needed to pretend to just be SSL 3 (hence TLS 1.0 was SSL 3.1, TLS 1.2 wsa SSL 3.3 aka 0x0303) and then even that rusted into place so TLS 1.3 pretends to be TLS 1.2 or else it won't work. So long as Perl ships new versions with new syntactical features every year or two, the propensity for things to rust into place can be curtailed, but imagine if Perl today and Perl from 2008 had the exact same syntax, by now some software would expect and require that syntax. New Perl would find that introducing features, even much needed and long awaited features, tripped this rusted into place hazard despite the supposed promise to be able to exercise this option. Ouch. You may have experienced something similar with muscle tone if you had "stay at home" restrictions during the pandemic.
Also, a steady pace of change means that tooling and culture adapts properly. If the last substantive change to Perl syntax had been in 2008, what's the chance automated testing catches syntax errors related to a new change made tomorrow? Approximately zero. But if such changes happen about every 18 months on average there's a good chance somebody actually wrote a test by now. Likewise if the last change was 2008 people who expect to be warned might not realise they weren't tracking this any more. People forget how the process works. If there are on average two features proposed every year, experienced users know how to read a proposed change, where to debate it, stuff like that. The community is prepared for, and equipped to handle change, because it's just routine.
Posted May 29, 2022 23:57 UTC (Sun)
by rra (subscriber, #99804)
[Link]
Perl has been exceptional at backward compatibility for many years. I have code I wrote in 1999 that is still running with no changes whatsoever. Given that, I'm happy to extend the benefit of the doubt and assume that this work will be done with the usual amount of care and deliberation, and I'm happy that they're working their way through the backlog of experimental features that were added to the language and then never resolved one way or the other.
Posted May 29, 2022 23:58 UTC (Sun)
by NYKevin (subscriber, #129325)
[Link] (3 responses)
Look, I've been there. I know that changes cause breakage, and I know that you can stop things from breaking if you stop making changes. The problem is, that's a short-term solution at best. For a few weeks or months, this can be highly effective:
* You had a bad week, you're all out of error budget, and you need some time to recover your SLO.
The problem is that this is not sustainable in the long run. You can't just freeze prod forever. The world is going to move on, with or without you. Eventually, you will need to change prod, and if it's been frozen for the past three years, then you are basically screwed, because you'll have to completely rebuild and redeploy absolutely everything, and make a massive change all at once. Some software won't exist anymore. Some software will exist, but will no longer be meaningfully maintained. Every piece of your technology stack is moving at a different speed, and you'll have to redo all of your version mix-and-matching from scratch. This is much, much riskier than smaller, incremental changes on a more frequent basis.
A language that barely changes is not a good thing. It's a liability. Eventually, developers will tire of working in that language, because it is missing features relative to other languages, and some of them will stop maintaining libraries and other stuff that you (probably unknowingly) depend on. Or they will get old and die/retire, and nobody will be interested in picking up the work, so it will go unmaintained by default. It's the https://xkcd.com/2347/ problem, but on a language-wide scale.
Posted May 30, 2022 14:24 UTC (Mon)
by tialaramex (subscriber, #21167)
[Link] (2 responses)
One of the problems we repeatedly had in the Web PKI is that institutions will agree that "End of next year" is an acceptable last cut off, but then as December Y+1 approaches, they suddenly remember that they've got a "No changes during the holidays" policy - once their employees sign off before Thanksgiving (or similar) they won't make any changes until after New Year - and so, now they want the thing they agreed for December pushed back to February. Nope, if you really can't make changes during the holidays, when you agreed "End of next year" you needed to schedule in work before the holidays to hit that deadline. That's how time works. You aren't being "pragmatic" or showing "foresight" you are in fact incompetent because you are going to fail and then redefine it as success.
However, some of this stuff is getting easier as our industry matures. Examples: There probably won't ever be another encoding for the character 'A' having settled upon 65. If your code written in 1985 chose ASCII 'A' of 65 it's still fine today in an environment where UTF-8 'A' is deliberately also 65, while some of the other 1960s encodings did not agree. There's a good chance you'll never need a different symmetric encryption algorithm, AES is fine for conceivable problems. It looks like we're agreed that the octet is a byte and too bad if that's inconvenient. Even some ideas in programming are probably here to stay. As a result, although I agree change is constant and it's something Perl is wise to embrace as necessary and good, we shouldn't expect more seismic changes, often or perhaps ever. If Perl 7 ever does happen, I expect it will be less different from today's Perl than that Perl is from Perl 4 despite the big number.
Posted May 30, 2022 16:21 UTC (Mon)
by NYKevin (subscriber, #129325)
[Link]
Posted May 31, 2022 23:12 UTC (Tue)
by bartoc (guest, #124262)
[Link]
Posted May 28, 2022 2:58 UTC (Sat)
by rsidd (subscriber, #2582)
[Link] (1 responses)
Python continues to dominate despite all the whining about python 3, because it is a good language that continues to add new features (eg, recently, pattern matching which is something I sorely missed from ML-type languages like ocaml). A bit longer ago, python 2 added list comprehensions (borrowing from haskell) which I personally use all the time, far more expressive (to my eyes) and more concise than map+filter. Who wants to use python 1 today?
Posted May 31, 2022 9:16 UTC (Tue)
by anton (subscriber, #25547)
[Link]
Posted May 30, 2022 15:11 UTC (Mon)
by jafd (subscriber, #129642)
[Link] (2 responses)
What happened to Perl 7?
What happened to Perl 7?
What happened to Perl 7?
What happened to Perl 7?
What happened to Perl 7?
What happened to Perl 7?
What happened to Perl 7?
What happened to Perl 7?
What happened to Perl 7?
What happened to Perl 7?
What happened to Perl 7?
* If the object instances can interact with each other, now you have to figure out the semantics of this interaction for each possible combination of versions.
* If the language supports generics and the object is first-class, can a generic class from the old version match (be instantiated with) the type of the new version?
* If the language is dynamically typed, good luck getting any of this right.
What happened to Perl 7?
What happened to Perl 7?
What happened to Perl 6?
What happened to Perl 6?
What happened to Perl 6?
What happened to Perl 6?
What happened to Perl 6?
What happened to Perl 6?
What happened to Perl 6?
What happened to Perl 6?
What happened to Perl 6?
What happened to Perl 6?
What happened to Perl 6?
What happened to Perl 7?
What happened to Perl 7?
What happened to Perl 7?
What happened to Perl 7?
What happened to Perl 7?
What happened to Perl 7?
What happened to Perl 7?
What happened to Perl 7?
What happened to Perl 7?
What happened to Perl 7?
What happened to Perl 7?
What happened to Perl 7?
What happened to Perl 7?
What happened to Perl 7?
What happened to Perl 7?
What happened to Perl 7?
* Your company is having a big presentation or other event, and it would be really embarrassing to have an outage right at this moment.
* It's the holidays, and you really don't want to be stuck troubleshooting a production issue from your parents' house, while your great-but-technologically-illiterate uncle is trying to sell some cryptocurrency scam to your second cousin downstairs, when you would otherwise be able to prevent that transaction from taking place.
What happened to Perl 7?
What happened to Perl 7?
What happened to Perl 7?
What happened to Perl 7?
I was puzzled by what you wrote, but I think you meant: "Pattern matching is something from ML that you sorely missed in (earlier) Python."
What happened to Perl 7?
What happened to Perl 7?