Re: C<strict> as default (was Re: RFC 16 (v1))

There are two distinct groups of people on this list, which I would
argue are never going to reach consensus:

   1. Those that develop applications in Perl
   2. Those that use Perl as one tool in their toolbox

I'm a sysadmin so I'd say I mostly fall in #2. While I do indeed do #1
(and "use strict" in those cases, including my CPAN modules), I
primarily use Perl as a tool that can pull apart regexp's with the ease
no other language can.

One key tenet in open network technologies is "be liberal in what you
accept, but be conservative in what you generate". I think this is key
to this discussion. Perl should be liberal in what programs it accepts.
Programmers should be strict (conservative) in what they produce.

As a sysadmin, I would loathe the day that Perl decided to turn on
strict by default. Why? Because I have a set of requirements that have
never been mentioned: I have to maintain Perl for a site of hundreds of
users, all with different requirements. 

Consider Bob, who knows our site has Perl. Bob doesn't know any Perl,
though, but he downloads a CGI script from the web that's a simple
counter for his homepage. He tries running the script, but is
overwhelmed by the 100's of messages about "global variable $var
requires explicit ..." that are spewed out. What does all this junk
mean??? We have Perl, it should work! That's what the website I
downloaded it from says!

You know who he calls? Me. "Why is our site Perl broken!" he yells.
"This script should work!"

Don't make me field calls like this, PLEASE. Perl already has the
ability to turn strict on for projects where it's needed. If you can't
trust one of your programmers to type:

   use strict;
   use warnings;

How can you trust *any* of the code they produce?!?! 

-Nate