top | item 40888425

(no title)

mfontani | 1 year ago

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

discuss

order

bachmeier|1 year ago

> 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|1 year ago

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.

gwervc|1 year ago

> 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|1 year ago

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

zelphirkalt|1 year ago

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

croes|1 year ago

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

ajsnigrutin|1 year ago

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.