3 ms·

This is just one case of the chain of “logic” so many people seem to make with software, for some reason: - I got your code for free - I set up Really Importa

This is just one case of the chain of “logic” so many people seem to make with software, for some reason: - I got your code for free - I set up Really Important Things using it - I have contributed nothing to you, for years now - I have also invested nothing in maintaining my Really Important Things (e.g. it is no one’s job at the company) - How dare you change anything!!

deleted 5y ago
[deleted]
ivanhoe 5y ago
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)
ourmandave 5y ago
Like a blockchain.
sosuke 5y ago
This might seem like a stretch. But could hiring people to work on Really Important Things be interpreted as a form of support?
- bombcar 5y ago
  "Really Important Things" are usually business-internal software (for example, there are likely thousands upon thousands of perl scripts mangling data for company systems, where the original developer is long gone but they continue to work). Developer time spent on that doesn't really benefit the community as a whole beyond a blog post here and there about some aspect of how to set it up. And when that software breaks on an OS update (say CentOS 6 -> 8) is when often "virtualize that machine and keep running the old code" becomes the answer.

deleted 5y ago

[deleted]

ivanhoe 5y ago

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)

ourmandave 5y ago

Like a blockchain.

sosuke 5y ago

This might seem like a stretch. But could hiring people to work on Really Important Things be interpreted as a form of support?

bombcar 5y ago
"Really Important Things" are usually business-internal software (for example, there are likely thousands upon thousands of perl scripts mangling data for company systems, where the original developer is long gone but they continue to work). Developer time spent on that doesn't really benefit the community as a whole beyond a blog post here and there about some aspect of how to set it up. And when that software breaks on an OS update (say CentOS 6 -> 8) is when often "virtualize that machine and keep running the old code" becomes the answer.