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).

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.)

How many times has a person come here asking why code they found online or pieced together themselves doesn't work when it's something that would have been resolved if they knew to use strict and warnings

And the answer is of course, "Many, many times". However, if Perl7 in its proposed guise does come to pass then your question will subsequently become:

How many times has a person come here asking why code they found online or pieced together themselves doesn't work when it's something that would have been resolved if they knew to use compat::perl5?

because there's so much old, old code out there which will break on Perl7 because of the lack of backwards compatibility. Some of it is, no doubt, truly woeful code that would be better off being binned and re-written anyway [hippo waves at formmail.pl] but much of it (and an increasing amount as time goes on) is perfectly usable code under Perl5.

So Perl7 needs to cater for newbies who find old code which suddenly fails and also to folks like salva who already have lots of old code which suddenly needs to be rewritten to be portable to both existing and new perls. A vast amount of effort will be required to educate all manner of users and I fear that the Monastery will need to put about 3 or 4 FAQs on the homepage and prominently elsewhere to prevent a deluge of similar questions.

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's not even that, is it? The pragma will fail on Perl5 so how can you trivially change the old code to be portable to both? Suddenly it becomes a considerable maintenance task.

Perhaps the real problem with this plan is that those who have proposed it have only been working with super-clean PBP-approved code for the last 5 years and have underestimated the sheer volume of older, looser code which is in active use more generally. It would be good to think that a feasible approach could be reached which caters to all but I for one can't quite see what it would be.

> have lots of old code which suddenly needs to be rewritten to be portable to both existing and new perls

Hmm ... shouldn't including something like use 5.10.0 imply use compat::perl5 when run under Perl 7 or later and how would this brake old code?

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery}

Mmmmmm… usually when people come here with questions about old code NOW they are told, paraphrasing but… That’s crap, don’t do that.

«...I have modules that don't use strict or warnings; I have code that uses bareword filehandles...»

You're fired!