[mfontani]

> And still no native object/class system.

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]

> I really, really like that I can, more often than not, take a program I wrote decades ago and it will still run properly.

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]

That depends on "which version" of "Perl 7" you're saying, as IIRC there were various "factions" that had varying ideas about what ought to happen when "perl7" runs programs that didn't specify a "use v..." or that specified a specific "5.something" version.

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.

[bachmeier]

> 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.

Yeah, and that was one of the main reasons cited when they announced Perl 6, back in 2000. 24 years have passed and it's still an issue.

[gwervc]

> I really, really like that I can, more often than not, take a program I wrote decades ago and it will still run properly.

"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]

> C where a codebase from 15 years ago will compile and run just fine.

You can fix this by using -Wall -Weverything -Werror to ensure in 15 years time, the code won't compile any more.

[ninkendo]

Tangent: I wish more projects/build systems had a distinction between modes of “I'm the developer” vs “I’m just a poor soul trying to compile this”. -Werror is appropriate for the former but not the latter. It sucks when some random dependency stops building because they put -Werror in their makefile and the compiler added a new warning at some point that didn’t exist when the code was written.

I’d actually go even further and say that the only appropriate time to use -Werror is when running tests for code that hasn’t been merged yet… once it’s “released” you don’t want to use -Werror any more.

Ditto automatically running unit tests/etc too. (Perl is actually a major offender here… last time I used Perl, installing a module from CPAN would run its unit tests by default. Why do I, some random person installing this module, care if the tests pass now? The tests should have been run prior to this being published! I have horrible memories of the DBD::MySQL package failing to install because it ran tests that assumed localhost was running a MySQL server with anonymous auth enabled and the whole module failed to install if that wasn’t the case.)

[mfontani]

> Why do I, some random person installing this module, care if the tests pass now?

Because running those tests in your environment ensures that... that module can run in your environment.

By way of example, if a module requires a specific library installed to actually run, running its tests will ensure you catch the problem, and install it, so it can then actually run. Else you'd only find out at runtime that something's missing.

Note also that not all tests are the same, and (unfortunately!) not all modules' tests are the same, either: there's tests that ensure the module works "generally", and there's some author/development tests that on a _properly written_ module are only ran by the author/developer, and skip running when the modules are instead installed by mere users, for whom instead the "standard" "will this module work in this environment?" tests are the only one that get ran.

> I have horrible memories of the DBD::MySQL package failing to install because it ran tests that assumed localhost was running a MySQL server

I believe that got fixed, IIRC, as I've had no trouble installing that module (and running its tests at install time, natch). I said "fixed" as that seems like the sort of test that makes sense for the module's authors/developers to run, and not mere users of it.

[zelphirkalt]

I think what you describe fits JS better. Already migrated your router library for your react project, this month? What, still not migrated!? No one is building things for X any longer! You need to switch to Y asap!

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".

[joelwilliamson]

https://docs.python.org/3/whatsnew/3.12.html#removed

Here's a list of things that were removed from Python in 3.12, most of were deprecated after the 3.0 release.

[croes]

For C# only if the necessary framework version is installed.

[ajsnigrutin]

Not just that, but cook kids change their languages weekly! HN is full of threads named: "<existing software> written in <language of the week>", and we all know how many people use that emacs fork written in ruby today, and how many will use the one written in Go in 10 years.