Perl is the language of AND rather than OR, and there is more than one way to do it, so I personally don't value categorical imperatives about best practices too highly.

I think best practices are quite different from categorical imperatives: at least all of the best practices I follow, I do so because I was convinced by the good arguments for them and my own experience with them. For example, I can still remember all the time I used to spend proofreading my code for typos. And I hope very few of the patterns I use are still cargo-culted :-)

I'm also a big fan of TIMTOWTDI; I think it applies in a lot of places, even including the use of strict and warnings. However, I think there's a difference between knowing all the good arguments for strict and warnings and knowing when it's ok to turn them off, and ignorance or denial of the good arguments for strict and warnings. Since this is a website for Perl help, we tend to get the latter more often than the former, so we're probably biased...

I do have to say your argument for rapid prototyping doesn't apply to me, when I'm whipping up a prototype I prefer to get all the support I can so that I don't make the kinds of silly mistakes in my prototypes that strict and warnings help to catch. So your choice seems to be simply a stylistic one (at least I don't see any technical arguments against strict), which of course you're free to make!

But also, note that people who refuse to maintain non-strict code are maybe doing so not just because of dogma, but also because they have had debugging and maintenance nightmares resulting from the absence of strict. And I also wrote a bit about why strict and warnings are appreciated on a help site like this one here. So those are some reasons why you will get pushback.

Well said! I think your perspective on strict also depends on your background. If you've done a lot of things in awk before coming to Perl, you'll appreciate why it can be useful not to use strict. But you'll also appreciate the benefits that strict provides. The great thing about Perl is that it allows both strict and no strict and even somewhat strict.

If you've done a lot of things in awk before coming to Perl, you'll appreciate why it can be useful not to use strict.

I admit I haven't, but if you mean oneliners, then yes, those are usually written without strict and warnings and it leads to more concise code with its own kind of beauty. At least in my mind, omitting strict and warnings in oneliners is usually acceptable because they are so short that proofreading and testing them is a relatively simple task.

(OTOH, roughly 95% of the oneliners I post here I actually develop with -wMstrict turned on, only to then remove the switches once I'm satisfied the code works, so it gets shorter and fits on one line. An artifact of this that some might notice is my abuse of $a and $b due to them being exempt from the checks...)