Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked
 
PerlMonks  

Re^7: Modernizing the Postmodern Language?

by salva (Canon)
on Jul 03, 2020 at 15:26 UTC ( [id://11118874]=note: print w/replies, xml ) Need Help??


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

As someone who 'knows perl', adding a one line pragma to keep your wild and crazy weekend coding lifestyle intact is hardly an onerous task.

But it is quite the contrary, it would be much easier for me to say no strict the very rare times I need it than use strict all the other times.

The issue for me is breaking backward compatibility just for that, for so small gain.

So, let me express it in a different way: you come to me saying we are going to break backward compatibility because ...

  • we are adding a full OO system, which a proper MOP, and now classes are also objects, so we need the SV STASH slot to be an SV instead of an HV and that is going to break lots of XS code.
  • or we are adding support for masive multithreading, the old threading model is being removed
  • or we are removing deterministic termination because we are puting a garbage collector in place
  • or we now are going to be throwing proper exception objects from the core and adding try/catch
  • or we are fixing all the unicode bugs and making Perl default to the world-is-unicode
  • or fix all those edge-cases and features that are in the language but that never were completed
  • or adding optional typing
  • or a new runtime with a 3x increase in speed
  • or Android support
  • or a transpiler to Javascript
  • or etc., etc., etc.
... then, I would say, go ahead, that's the way I want Perl to follow.

But instead, they are saying, we are just releasing perl 5.xx as perl 7, changing some defaults and so, my old code may become broken, the applications I wrote for my company may become broken, the modules we use from CPAN may become broken (and by the way, break my code and my company apps in some other ways). I would have to revisit my code, convince people to fix their modules on CPAN, or just apply for maintanership, or fork them, and keep then in our private ForkedPAN.

Also, what is worse, as you are not adding a "use v7" in your perl 7 code, when in a couple of years perl 8 comes out, it is going to break some of it again, because it is going to apply the perl 8 semantics to perl 7 code.

So, in summary, don't get me wrong, I sympathize with what the p5 porters are trying to do. I understand the limitations they are facing, the scarce man power they are, and that they want to announce to the world that perl is well alive.

But I also think that they should be more ambitious. I would like perl 7 to be what we expected from perl 6 (instead of what it became): a new powerful language with the syntax of perl 5 (extended).

Replies are listed 'Best First'.
Re^8: Modernizing the Postmodern Language?
by chromatic (Archbishop) on Jul 04, 2020 at 21:47 UTC
    you come to me saying we are going to break backward compatibility because ...

    I think the plan is saying that, or maybe "we're going to break backward compatibility so that we can".

    my old code may become broken

    I don't think that's going to be the case. Code that's not explicitly marked as 7-safe should continue to work as 5-safe.

    (Whether that happens in practice is still in discussion, as I understand it.)

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://11118874]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others surveying the Monastery: (8)
As of 2024-04-25 11:14 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found