I've already explained why it helps, and I'm not lying when I say it does help. 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.

(Also, perl -w warns you if you only use a variable once, so I don't think your example is valid. Of course, if you misspell it the same way twice, then you have problems.)

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.