You may see those "best practices" as an end in itself. I don't. I consider those practices something useful that allows me to write better code, catch more errors, etc. and that's why I use them. But then, if for some reason I get to some place where they get in the way I just ignore them without a blink.

I have modules that don't use strict or warnings; I have code that uses bareword filehandles; probably, I have code that goes against any "best practice" of those that could become forced in perl 7.

And it is good, reliable, beautiful code...

And it's okay because you know Perl. You understand when and why strict, etc. might "get in the way" and how to keep working without them without having the world fall on your head. But the people who already 'know perl' and don't want to change aren't the audience for the future of perl7+. From the announcement, it's clear that the future of perl is targeted towards allowing people who do not currently know Perl to come into it with a standard foundation that even you admit helps you write better code. 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 if the message generated made any sense but that's an entire conversation itself)? The first few months of learning Perl is mostly "oh, I forgot to use strict before and now I see what's wrong." After all these years, I don't see how you don't agree that such basic 'best practices' should just be standard practice for people new to Perl who'll be writing "better code" from the start.

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. Because you'll be aware it exists and understand the impact, it's not nearly as much of a hindrance as flat out not knowing to use strict. ¯\_(ツ)_/¯

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

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.

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

You're fired!

«The Crux of the Biscuit is the Apostrophe»

perl -MCrypt::CBC -E 'say Crypt::CBC->new(-key=>'kgb',-cipher=>"Blowfish")->decrypt_hex($ENV{KARL});'Help

If your code only works properly without strict, wasn't your code already broken? And broken by design?

that! (*points at you*) is the attitude that disgusted me so much from the announcements. SawyerX, is that you? LOL

Wow. I don't know if it's still true today, but back when Perl was actually popular there were 1,000 "single-screen scripts" out in the wild for every CPAN module or application framework. And, emphatically and forever, I say it's silly to call those broken by design, or bad code, just because they didn't put unnecessary constraints on themselves.

Anonymous, I script everything. Bash, sed, perl, python, lua, pwsh, and tons of others (but never once in awk, true fact). I write scripts that write scripts so I can script while I'm scripting. And I am here to bring you the good news that there is a wide wide spectrum of scripting tasks out there, and one size does not fit all.

So sure, when you get past that one-screen level of script, you start to care more about misspelling a variable, and you don't mind spending a couple lines of code making sure $3 isn't undef before you splice it into a string. Probably 2/3rds of my perl scripts are strict+warnings, and factored into modules, and all that. But, Anonymous Monk, listen to me now and hear me later: the single screen, non-mission-critical, just-lives-in-my-$HOME scripting... the -p scripting where $cnt++ comes out of nowhere but totally has your back when you need the count at the END, is some of the best scripting there is. That's the 20-minutes of scripting that does the next 8 hours of your job while you browse XKCD. Don't miss out on that scripting, Anonymous.

Broken? ...like a fox!

I'm AM because the only people left on Perlmonks are those who will disagree with you out of spite and then hassle you for no reason until you just log out and forget your password. Look at your comments in this thread... you don't even really disagree with my comment but still swing between imagining I don't know that darkpan exists and can't grasp that some small scripts are one-offs that do a very small, specific task and do not need to be perfect as long as they work. But in the time it took you to write all that condescending noise, you could have tested and 'fixed' several of your little pet scripts that might not be strict-ready and be done with it. Instead, here you are, defending your right to not put `my` in your code.

…the only people left on Perlmonks are those who will disagree with you out of spite and then hassle you for no reason…

Present company excepted, of course. :P

you don't even really disagree with my comment

I don't even ... what now?

I completely disagree with your original comment, both in tone and in content. I disagree somewhat less with your present comment.

imagining I don't know that darkpan exists and can't grasp that some small scripts are one-offs

Your original post concisely divided the world into (a) strict code, (b) one-liners, and (c) maintenance nightmares. I don't see how I can be expected to imagine that you know about darkpan and the plethora of useful one-off scripts, but so be it--let's just agree that my psychic powers did not kick in as expected, and I mischaracterized you as a result. Salva's replies were more measured but also were a recap of posts we already have here. This was a useful discussion for me, and I really don't want it to devolve into arguments. So, rather than going in circles, I think I will log out and forget my password. :-)