For the first several years of the Perl programming language, there was no strict pragma. Variables were effectively global. Barewords were okay. There was little protection against typos—certainly no compiler support for finding them before they caused bugs in your programs.
People wrote a lot of code in those conditions. Even after Perl 5 came out,
because strictness of variable declarations, barewords, and references were all
optional, people still wrote a lot of code without strict enabled.
A lot of that code worked. (As Mark Jason Dominus points out, Perl's
strict pragma is not a magic "fix my code" button.)
With that said, I enable strict in every serious
program I write, at least every program that's not a one-liner stuck in a shell
alias somewhere. The Modern::Perl
pseudo-pragma enables strictures, and I encourage novices learning
from anything I've written to use it.
For me, it's about limiting risk. I know I make typos. Having
perl check that I haven't misspelled a variable or a function name
is a tiny little piece of peace of mind that limits the damage I can do from a
silly mistake. (I don't find strict reference checking all that useful, because
I use soft references very rarely and in very deliberate circumstances.)
For others, it's about helping them to learn. It's difficult enough to learn
the semantics of a programming language when you're learning the syntax and
idioms too. Yes, use strict; is a small piece of boilerplate magic
that a novice might not understand for a while, but a beginner is more likely
to make more frequent and more severe beginner mistakes than an experienced
programmer. I need a safety net to help me avoid typos, while a beginner needs
a safety net to train him or herself to avoid beginner mistakes as a habit.
Habits are important. They're indicators. They're signals. They can be subtle, but when you see a program which starts:
require 'cgi-lib.pl';... you probably already have a pretty good idea of what you're going to find. (The program may be great, but it may violate some RFCs about the CGI protocol and it's probably not great at all in fact.)
When you see a CPAN distribution with a t/ directory with only one file, t/00-boilerplate.t that's a few dozen bytes in size, you probably have a pretty good idea of the quality and maturity of the code. (The code may be great, but you're going to have to do a lot of work yourself to prove that.)
When you see someone complain that "PERL is unreadable", you probably have a
pretty good idea about the kind of code he is referring to. (That code probably
starts with require 'cgi-lib.pl';, or at least would be less buggy
if it did).
These aren't markers of your worth as a person. They're not markers of the
quality or utility of your code. They make no promises of the presence or
absence of bugs of intent, and they're not guarantees that there are no bugs of
typos. (Would strict be more useful if it could somehow enforce
strictness of hash keys?)
The direct and pragmatic value of strict is that it does offer
a minimal level of assistance from perl to avoid common behaviors
which are often mistakes. They're not necessarily mistakes in very short code,
but when you get beyond a couple of hundred lines of code, they're risky. It's
easy to overstate its value, even for pedagogic purposes.
It's more difficult to overstate the value of strict as a
signifier. It's a symbol. It's an indicator. You're at least making the attempt
to avoid silly little errors. The lack of strict oughtn't imply
the opposite, but if you're starting out with Perl and using
strict, you're at least trying to let the language help you.
That's a start.
Like almost anything else in Perl, this oughtn't be a dogmatic rule. The language exists to help you get things done, not to train you to conform to some language designer's theoretical ideals. (But there are theoretical ideals underpinning the design of the language, and you'll have an easier time solving your problems with the language if you design your programs to Perl's strengths.)
