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.
In reply to Re^5: Align given substring(s) in lines
by haukex
in thread Align given substring(s) in lines
by johnaj
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |