(no title)
mfontani | 1 year ago
There's https://metacpan.org/dist/perl/view/pod/perlclass.pod, which (granted) is experimental, but it's actively being worked on.
> Still no working exception handling!
There's https://metacpan.org/dist/perl/view/pod/perlsyn.pod#Try-Catc... which is now (5.40) no longer an experiment, _aside from_ the use of `finally`, which warns.
> trying to guarantee backwards compat for all the legacy code
Not "all", as there are indeed deprecations added over time, but _most_. I really, really like that I can, more often than not, take a program I wrote decades ago and it will still run properly.
bachmeier|1 year ago
That wouldn't have changed with Perl 7, because Perl 5 would have been put into "long term maintenance mode". In fact, backward compatibility would have been even stronger, because all the changes would have gone into Perl 7.
mfontani|1 year ago
I'm personally of the idea that enough backwards compatibility _should_ be preserved, but not _so_ much as to inhibit new/better syntax constructs and the like.
But honestly it's the sort of thing that is more like "I'll know it when I see it" more than anything.
Re "long term maintenance mode", there's the not so small matter of how many people can, in fact, actually develop perl. The codebase is large and full of many traps. It's a difficult, but not impossible, codebase to contribute to.
My sincere hope is that enough things will get out of "experimental", including quite a bit more of the "class" feature, for the end result to be enough to be called "7" and we'll go from there.
Basically... mostly a marketing thing, as today's 5.40 is way, way different (and better in so many respects) than 5.8 or 5.20 or even 5.32... but the (minor) version number doesn't show that.
A "perl 7" would.
gwervc|1 year ago
"Cool kids" languages like Python and Rust really put in the mind of people that a program written two weeks ago must be upgraded to run on the new version of the compiler or interpretor. Meanwhile there always have been languages like C# or C where a codebase from 15 years ago will compile and run just fine.
michaelt|1 year ago
You can fix this by using -Wall -Weverything -Werror to ensure in 15 years time, the code won't compile any more.
zelphirkalt|1 year ago
I am not aware of anything in current Python 3, that has broken backward compatibility to an earlier Python 3.
Some dependencies are implemented in ways, that will require you to use newer Python versions. Often those are packages, which are glue for lower level libraries. Like tensorflow.
Perhaps I am describing the same thing as in JS ecosystem. But for some reason neither have I migrated to another way of defining my API routes in Django lately, nor have I had any need to in the last couple of years. I guess in the JS world there is just so much more half-backed stuff that gets hyped to no end, and this job guarantee is celebrated as "quick evolution".
croes|1 year ago
ajsnigrutin|1 year ago