I think you misunderstand me. I also like set-and-forget semantics... at least to function. I would be very unhappy if Perl stopped doing cleanup as scope exited and my screwups resulted in instant malfunctions rather than warnings. I just like to be gently thwapped with a wet noodle when I forget something obvious enough that a compiler can spot it. But I want the language to be only my fallback, because if I stop trying to outperform the automated cleanup, if I stop trying to make sure that I will always, always be able to figure out what I was doing in a chunk of code a year after not looking at it, eventually I am going to come back to code only held together by the automated cleanup and make a mistake too subtle for either me or the compiler to notice. And if I pass that code onto someone else, some year I'm going to download an updated version where someone else made a subtle mistake, or had to rewrite a chunk of it, and wonder if it was my fault.

And that's why I want to be able to get warnings on "stylistic" issues. I keep looking for ways to turn on extra warnings without slowing down my main work too much. A lot of what I want can be implemented in subsequent unit tests (and in fact one of the first things I did on my recent project was set up a sample input with a lot of weird things wrong with it and run my code against every time I made a change), but one of the major strengths of a scripting language over a compiled language is the instant feedback from when you did something wrong. I like that.

I know there's a culture clash thing going on here, and my approach probably comes off as plodding, paranoid, and clunky to people who have taken code golf and functional programming to a fine art form, but I like to think that one of the things that we can agree on is that (at least as of a week or so ago, when 0.02 of warnings::unused showed up), Perl allows a wide enough range of expression to work for both of us.