Like with perl, I'm not always wanting to use strict and warn; I like not having to predeclare all my variables, for one thing...(and sometimes I'd have to lookup how to predeclare some kinds of hashes and arrays...)

I generally only use strict for larger programs, modules and include files that I intend to reuse, and code that's going on the CPAN for other people to see. Warnings are invaluable, but I can see why someone would want to ignore them: there are one or two warnings that *usually* don't indicate any problem. Most notably, the "use of uninitialized value" warning: if it ever did indicate a real bug in my code, I'd never notice, because after hundreds of thousands of times when it was meaningless I've learned to ignore or work around it. OTOH, if you ignore a "useless use of foo in void context" warning you're almost certainly making a significant mistake. ISTR that Perl6 is going to give us the ability to shut off individual types of warnings and still see the others, which IMO will be very helpful.

As far as bad coding: you can write bad code in any language, or decent code in most languages, that much is true, but some languages *do* make it easier or harder to write good code. Something I like about Perl is that it makes it easier to refactor shoddy but working code into better code relatively quickly; in some cases I've found myself going into the code with the intention of adding features and refactoring things "while I'm at it". Often I write quick-and-dirty code initially to get something working and then refactor it once it's running. I didn't do that in the other languages I've worked in, because refactoring was much more painful. For example, I really liked the Inform language, but refactoring Inform code was excruciating, so it was important to think through the design and write it right in the first place. The same is true to a lesser extent of BASIC and lisp.

Then there's C. If ignoring warnings makes bad code, have you ever seen anything of nontrivial size written well in C? It seems to me that every project of more than a couple thousand lines in C (which doesn't go nearly as far as a couple of thousand lines of Perl would go) has compiler warnings coming out the wazoo. It's epidemic. Whereas, if I grab a Perl module off the CPAN and there are warnings during compile I start worrying about whether the module is low quality or maybe there's something wrong with my environment that's causing the warnings (e.g., something else not installed that should be).

Then again, though, tests run the other way. I've not very often seen an otherwise-working C program refuse to install because it failed one of its tests. This happens all the time with Perl modules from the CPAN, usually because either the test is just plain broken or more often because the test requires some other module to be installed that the module itself doesn't require. When it comes to things the Perl community needs to work on in terms of code quality, this IMO is a major thing. That, and one of the CPAN testers should run everything under Taint checking to catch modules that aren't Taint clean.