Sorry for the length, but I felt inspired tonight...

 > Of course it is _related_ to Perl.  Yes, you can write better or worse
 > Perl code.

 > In fact, one way management can bring about good coding styles without
 > examining each and every line of code is by choosing tools and
 > languages that enforce some aspects of good coding styles.  Perl isn't
 > one of those languages.

Short form: (1) there's a tension between early detection of faults
and rapid prototyping, and perl and python are at very different
points on the spectrum.  (2) it's more the community around a language
than the language itself that influences code quality.
(3) For my purposes, perl will continue to be a work-horse tool, but
I'll be using Java more for things that I would have used python or
Modula-3 for, and I hope the industry uses Java for things that
it has been using C++ for.

Long form:

(1) Traditional perl programming is a black art, but a darned useful
craft as well. The semantics are very powerful, and the syntactic
features combine in amazingly powerful ways. But you definitely have
enough rope to hang yourself; not enough to hang the machine or crash
all the time, like the way you can corrupt the runtime in C by writing
past the end of an array or calling free() twice. But like C, you can
introduce subtle logic bugs by using = where you meant ==. And
failing to check return values results in a program that nearly always
reports successful completion, whether it really succeeded or not.

I like studying and learning programming languages, and I found it
more difficult to build the necessary intuitions to read and write
traditional perl programs than to build intuitions for any language
I leaned previously, and nearly every language I learned since.

I learned perl "from a master" -- Tom Christiansen was in the next
office, and he painstakingly (if not patiently :-) answered my many
frustrated questions. Previous to learning perl, I had learned a dozen
or so languages without much difficulty (here in roughly the order
I learned them):

        Extended BASIC (Radio Shack Color Computer)
                learned from a book, disassembled the interpreter
        6809 assembler
                learned from a book with a friend, and from
                disassembling LOTS of stuff
        Basic09
                learned from the manuals, with help from BBS folks
        Logo
                learned in a store one afternoon, reading a book
        Pascal
                learned one summer from a college professor
        C
                read a book one weekend
        COBOL
                learned at a summer job
        shell
                misc. hacking in school
        LISP
                read some books, hacked on TI lisp machine in a class
        prolog
                programming languages course
        Modula-2
                programming languages course
        Ada
                programming languages course

Learning assembly after basic was tough: "Where are the variables?
Geez.. rebooting the machine all the time is a pain. I wish this thing
had automatic string handling." And I'm not sure I ever grokked Ada's
rendezvous stuff completely. And I learned COBOL in a strictly
monkey-see-monkey-do manner. It was months before I found a manual.

None of those were particularly unexpected difficulties. But after
an intial taste of perl, it looked really easy and powerful, and
I was frustrated when the first few real programs I tried to write
had bugs that I just could not figure out at all.

Really learning to use regexps was well worth the effort, but things
like "surprise!  <FILE> works completely different in an array
context!"  was an experience I don't care to repeat. I can't remember
the exact program that drove me batty, but it was related to:

        $x = <FILE>; # reads one line
        @x = <FILE>; # reads whole file, split into lines

but the idiom I used that created an array context wasn't as transparent
as @x -- it was something like grep() or chop(). Ah yes, I think
it was chop(). Who would have guessed that

        chop(<XXX>);

would read thew whole file?

Perl is full of short-hand idioms that are so useful that
knowledgeable perl programmer's would feel awkward writing them out
long-hand, and yet they can throw newbies for a loop. For example, the
work-horse idiom:

        while(<>){
                ...;
        }

is short for:

        while( ($_ = <STDIN>) gt ''){
                ...;
        }

roughly speaking; that is, ignoring the tremendously useful
feature of <> which processes files mentioned on the command line
(aka @ARGV) ala traditional unix filters, which would take me
about 10 or 20 lines to write out longhand, and about an hour
to get just right. Ah! and I forgot to mention that <XXX> is
an idiom for reading one line from a file... and lines are
delimited by the magic $/, and ...

The point is that even as of several years ago, perl is a
highly-evolved, highly idiomatic language and tool, based on zillions
of person-years of use in unix system administration. The vast
majority of text-processing/system management tasks that folks might
want to hack up a script to tackle can be developed quickly, expressed
succincly, and run efficiently in perl.

The first crack usually looks like:

        while(<>){
                if(/X-Diagnostic: (.*)/){
                        print "diagnostic: $1\n";
                }
        }

and it usually works great the first time you try it. Then
you add a few wrinkles, and before you know it, the task you
set out to do is solved.

Taking that piece of code that solves a particular problem, and
software-engineering it usually takes about 10x longer than it took
to develop in the first place (as these tasks are often personal
and transient, it's rarely worth the trouble anyway).

The author of the hack is generally in a position to restrict
the inputs to reasonable stuff (eliminating the need to deal with
corner cases) and check the output by hand (eliminating the need
to document and report errors in typical engineering fashion).

This is very much in contrast with other languages, where the
cost of solving the immediate problem may be significantly higher,
but the result is much more likely to have good software engineering
characteristics, such that it's useful to other folks or other
projects with little added effort.

For example, Olin Shivers described his experience writing ML
programs: they are a royal pain to get through the type checker, but
once they compile, they are often bug-free.

Python isn't that far along the quick-and-dirty vs. slow-and-clean
spectrum, but it's in that direction.

Contrast the work-horse example above with a loose translation to
python:

        import sys
        while 1:
                line = sys.stdin.readline()
                if not line: break
                ...

incorporating the @ARGV parts of <> would expand it to something like:

        import sys

        for f in sys.argv[1:]:
                in = open(f)
                while 1:
                        line = sys.stdin.readline()
                        if not line: break
                        ...

Python doesn't have special syntax for this sort of thing. So the
python code is more verbose and less idiomatic -- easier to grok for
the newbie, but harder to "pattern match," or recognize as a common
idiom for the seasoned programmer.

For an example of the stylistic slants of the two languages, consider
error/exception conditions. As a rule, in perl, errors are reported as
particular return values, whereas in python, they signal
exceptions. So in the error case, a perl code fragment will run
merrily along, while a python code fragment will trap out. In many
text-processing tasks, running merrily along is just what you
want. But when you hand that code to your friend, and he presents it
with some input that you never considered, python is a lot more likely
to let your friend know that the program needs to be enhanced to
handle the new situation.

I've seen exception idioms in perl, but they involve die and EVAL.
The runtime libraries don't die on errors, as a rule, and EVAL
is a pretty hairy way to do something as mundane as error handling.

Next, consider naming and scope. By default, perl variables are
global, so you almost never have to declare them. Local variables have
dynamic scope by default (ala early lisp systems) and traditional
statically scoped variables are a perl5 innovation.

On the flip side, python variables are local by default, so you almost
never have to worry about the variable clobbering problem.  (python
has some semantic gotchas of its own here for the folks who have
intuitions about traditional static scoping)

So far, I have discussed mostly the intrinsic aspects of a language
that vary along the quick-and-dirty vs. slow-and-clean spectrum.

But the point of this article is that:

(2) The comunity around a language -- i.e. the conventional wisdom,
history, documentation, and available source code -- has a lot
more influence of the quality of code developed in a given language
than the intrinsic aspects of the language itself.

For example, it's perfectly possible to write clean, well structured
programs in Fortran. But the bulk of traditional fortran has no
comments or indentation, and lots of GOTOs, global variables, and
aliased variables. The mindset behind fortran was that
hand-optimization was superior to machine-optimization -- a mindset
left over from assembler, and popularized by bad compilers.

COBOL has some really bad features (e.g. lack of local variables) that
make writing good programs hard, but don't come close to explaining
the astoundinly uninspired programming techniques I've seen employed
in some business/database apps I've seen. Stuff like writing 12
paragraphs (subroutines, or functions to the modern world) -- one for
each month of the year, with 12 sets of variables jan-X, jan-Y, feb-X,
feb-Y, etc., rather than using loops and arrays, which DO exist in
COBOL.

Perl, as a language, is evolving faster than the perl development
community. Perl5 in strict mode a reasonable modern object-oriented
programming language. But there are ZILLIONs of perl programmers, and
from what I can see, about 2% of them bought into the new
facilities. The rest of them are still happily getting their jobs done
writing perl4 code -- myself included.

Perl was useful and widely deployed before the OOP "paradigm-shift"
hit the industry. And a community with that much momentum doesn't
turn on a dime.

In contrast, python started from scratch after some earlier languages,
and had the benefit of looking back at REXX, icon, and perl, as well
as C++ and -- most importantly -- Modula-3. So documentation
encouraged some pretty modern concepts like objects and modules while
the python development community was still young.

As a result, consider the namespace of functions in the two systems:
the languages have roughly equivalent support: python has modules,
and perl has packages. But you might not know that from looking at
most of the code you see on the net: traditional perl folks rarely
use the $package`var stuff, while python folks use it routinely.
The perl5 movement is quickly changing this, but until recently,
perl programmers use the vast majority of perl's facilities without
ever considering packages, while python programmers run into the
concept of modules in the early tutorials.

For me, the bottom line is that I do a lot of quick-and-dirty stuff,
and I'm comfortable with perl4's idioms, so I use it a lot. I have
dabbled in perl5, but I'm not yet comfortable with it's OOP idioms.

I prefer the feel and syntax of python, but the "strictness" often
gets in the way, and I end up switching to perl in order to finish the
task before leaving for the day.

When I want to write "correct" programs, neither is good enough. I
want lots more help from the machine, like static typechecking. And
sad to say, when I want to write code that other folks will use, I
choose C.

As much as the industry adopted C++, I find it frightening. It
requires all the priestly knowledge and incantations of perl with none
of the rapid-prototyping benefits, gives no more safety guarantees
than C, and has never been specified to my satisfaction.

Modual-3 was more fun to learn than I had had in years. The precision,
simplicity, and discipline employed in the design of the language and
libraries is refreshing and results in a system with amazing
complexity management characteristics.

I have high hopes for Java. I will miss a few of Modula-3's really
novel features. The way interfaces, generics, exceptions, partial
revelations, structural typing + brands come together is fantastic.
But Java has threads, exceptions, and garbage collection, combined
with more hype than C++ ever had.

I'm afraid that the portion of the space of problems for which I might
have looked to python and Modula-3 has been covered -- by perl for
quick-and-dirty tasks, and by Java for more engineered stuff. And both
perl and Java seem more economical than python and Modula-3.