|
in reply to Re^2: Modernizing the Postmodern Language?
in thread Modernizing the Postmodern Language?
I think it is untrue also, but not completely. Simply becoming slightly more aggressive about "new features available by default" (or even not possible to turn off) coupled with moving slowly enough as to allow for old code to be updated with minimal effort is key. Breaking changes are fine, requiring total rewrites of broken scripts from version to version is not so fine. These days, most have been conditioned to accept breakages from version to version. There's even a defacto standard based on 3 digit version numbers that dictates when to expect breakages. For example, change from 5.30.0 to 5.32.0 - expect some minor breaks; from 5.32.0 to 5.32.1 expect no breakage; from 5.x to 7.x - whoa hold ur butts. Another reason I think we'd be better served with keeping 5.x and being more aggressive with new featuers on until the latest 5.x is SO different from (say 5.32.0) that it is literally a fully different major version. |
Re^4: Modernizing the Postmodern Language?
by chromatic (Archbishop) on Jul 14, 2020 at 00:20 UTC
|
moving slowly enough as to allow for old code to be updated with minimal effort is key
I get this argument, but say was added in Perl 5.10, released in December 2007. You must still explicitly enable it 12 and a half years later in Perl 5.32. The only thing that can break if say were made available by default is code that defines its own function named say.
How much more slowly can Perl move?
| [reply]
[d/l]
[select] |
|
|
You must still explicitly enable it 12 and a half years later in Perl 5.32.
You also have the opportunity to enable it implicitly with use 5.010; or use 5.032; or anywhere in between. That seems like a decent compromise to me - just one line to say to the interpreter, "Yes, I want all the latest features in this bundle". I don't begrudge that one line of boilerplate just so its absence enables a couple of decades of non-breaking backward compatibility.
| [reply]
[d/l]
[select] |
|
|
I don't begrudge that one line of boilerplate just so its absence enables a couple of decades of non-breaking backward compatibility.
While I strongly believe good code (and good protocols and good file formats) should include a version number to disambiguate meaning, it's always felt backwards to me that the burden is on users of new releases to enable new, non-experimental things to prevent users who don't update their Perl from having to update their code.
I heard just this week about a company migrating from Perl 5.8 to 5.26 or 5.28. That really doesn't feel like the most important group of users to optimize for: people who want a new Perl every decade-plus.
| [reply] |
|
|
|
|
|
|
|
|
|
|
|
|
> How much more slowly can Perl move?
From my vantage point the trouble is that there were times when it didn't move at all. "always moving forward even if slowly" requires that it is always moving forward, so the question I have is how many missed opportunities were there to make say available with out the feature pragma? I can't answer that, but over 12 years the answer is probably "many". FWIW I don't use say because my impression is that it's easier to just add \n, but moreover it's almost exclusively because I would have had to turn it on. So was the issue paralysis of some kind? Again, idk. But say is an excellent example of something that should have been turned on a long time ago. Maybe that's the first thing that should happen in 5.32.1. See what happens. I mean it can't be worse than wasting everyone's time arguing and splintering the community again (not directed towards you whatsoever, just a rhetorical statement).
| [reply]
[d/l]
[select] |
|
