http://qs321.pair.com?node_id=11119274


in reply to Re^3: Modernizing the Postmodern Language?
in thread Modernizing the Postmodern Language?

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?

Replies are listed 'Best First'.
Re^5: Modernizing the Postmodern Language?
by hippo (Bishop) on Jul 14, 2020 at 07:59 UTC
    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.

      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.

        ... about a company ... doesn't feel like the most important group of users to optimize for

        I am sympathetic to all points of view in this discussion and neighbouring ones as a way to improve Perl. I also dont have much at stake except that I like Perl and right now building a tool using Perl - so 6month salary. But so far I have not seen anyone mentioning the investment, past, present and future of companies using Perl. That is the money at stake. And I have not heard anyone saying "on behalf of this company or the other we support or oppose these changes". And I am happy not to hear these financial arguments. On the contrary Because, it seems that Perl can pick and choose. But in real life this is not how it works. Companies will oppose or push standards or even legislature just for money. Just a sanity check on my side.

        bw, bliako

        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.

        Philosophically I would agree. The move to v7 isn't a philosophical one, however; it's a practical one. From a practical standpoint I really can't see how having one line of boilerplate of maybe 10 characters or so can really be classed as a burden. To follow your path I would only need to add it once to my stock script/module template and we're done. And given that this replaces the current, longer boilerplate it's even better. Your new code is shorter, slicker and has all the new features and those still having to support 5.6.0 need do nothing. In the immortal words of the late, great Errol Brown, "Everyone's a winner, baby!".

        > it's always felt backwards

        Precisely correct, IMO. Same burden would be present if we had to do something dumb like use v7;. It's just a bigger "feature turn on" approach. I characterize this as opt in to new features versus opt out. Traditionally perl has done the former, which is what I call backwards and I contend is a big reason for the situation we're in. We just need to do the latter.

Re^5: Modernizing the Postmodern Language?
by perlfan (Vicar) on Jul 14, 2020 at 00:39 UTC
    > 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).