4 ms·

Well, unless Larry Wall suddenly decides to make those breaking changes this really doesn't apply to big community driven projects like Perl - they don't belong

Well, unless Larry Wall suddenly decides to make those breaking changes this really doesn't apply to big community driven projects like Perl - they don't belong to any one group of developers, so neither group can decide to break them as they wish. You simply can't just decide to break something that hundreds of people have invested thousands of hours developing because you've now decided that you need some new fancy functionality, it's just a rude thing to do. Even more importantly, legacy projects are the ABSOLUTE majority of Perl projects left alive, so breaking them would be even bigger screw up than the Perl 6 was. BTW, no one says that language shouldn't be improved - that's a problem that can be very simply avoided with proper versioning. Instead of pushing for breaking Perl 5 backward compatibility just to avoid having to add a few pragmas to the top of their files, why not just help efforts on making Perl 7 a reality finally? Perl 5 will then then be free to focus on supporting the old projects and fixing bugs, while Perl 7 can add whatever they wish without worrying of old stuff...

bombcar 5y ago
An example is the Python 2/3 debacle - it took forever and still isn't complete (and now there are documents on how to install Python 2 to run older software).
weare138 5y ago
>You simply can't just decide to break something that hundreds of people have invested thousands of hours developing because you've now decided that you need some new fancy functionality, it's just a rude thing to do. But how long can someone reasonably expect newer releases to support legacy code? It doesn't make sense to hold back the development of the entire language just to support software that's 20+ years old. >Instead of pushing for breaking Perl 5 backward compatibility just to avoid having to add a few pragmas to the top of their files Because it make it harder for people to learn modern Perl when you have to just through hoops to enable features people expect in a modern language. It would make more sense to have pragmas to disable features for backwards compatibility. Or like the article mentions, just use an older Perl distribution. If your codebase is really that old there's really not much reason to use the latest version of Perl.
- ivanhoe 5y ago
  > But how long can someone reasonably expect newer releases to support legacy code? IMHO as long as majority of your users are on a certain version, you need at least to provide bug fixes for them. > It would make more sense to have pragmas to disable features for backwards compatibility. That would require people to edit all their old scripts to add these pragmas, which defeats the very idea of backwards compatibility. If only people could agree on what "modern perl" is, then we could create a single pragma that would enable all the features expected by this modern perl in a single line. Or, we could just declare that modern perl to be the starting point of Perl 7, as it was planned. Problem however is that there's no even consensus on what are the features that should go into this modern version, and that blocks the language development far worst than not being able to implement breaking changes (and of course the fact that most of old maintainers have left the project and team is seriously understaffed)

bombcar 5y ago

An example is the Python 2/3 debacle - it took forever and still isn't complete (and now there are documents on how to install Python 2 to run older software).

weare138 5y ago

>You simply can't just decide to break something that hundreds of people have invested thousands of hours developing because you've now decided that you need some new fancy functionality, it's just a rude thing to do. But how long can someone reasonably expect newer releases to support legacy code? It doesn't make sense to hold back the development of the entire language just to support software that's 20+ years old. >Instead of pushing for breaking Perl 5 backward compatibility just to avoid having to add a few pragmas to the top of their files Because it make it harder for people to learn modern Perl when you have to just through hoops to enable features people expect in a modern language. It would make more sense to have pragmas to disable features for backwards compatibility. Or like the article mentions, just use an older Perl distribution. If your codebase is really that old there's really not much reason to use the latest version of Perl.

ivanhoe 5y ago
> But how long can someone reasonably expect newer releases to support legacy code? IMHO as long as majority of your users are on a certain version, you need at least to provide bug fixes for them. > It would make more sense to have pragmas to disable features for backwards compatibility. That would require people to edit all their old scripts to add these pragmas, which defeats the very idea of backwards compatibility. If only people could agree on what "modern perl" is, then we could create a single pragma that would enable all the features expected by this modern perl in a single line. Or, we could just declare that modern perl to be the starting point of Perl 7, as it was planned. Problem however is that there's no even consensus on what are the features that should go into this modern version, and that blocks the language development far worst than not being able to implement breaking changes (and of course the fact that most of old maintainers have left the project and team is seriously understaffed)