[Python-talk] Python advocacy help
dragonhawk at gmail.com
Thu Oct 5 12:03:49 EDT 2006
I told myself I wasn't going to get involved in this thread...
On 10/5/06, Kent Johnson <kent37 at tds.net> wrote:
> Kent Johnson wrote:
> > This site is focused on migrating from C++ to Python or Perl; it
> > compares quite a few constructs in Python and Perl:
> > http://www.strombergers.com/python/
> Just reading through these examples makes me shudder and fervently hope
> that I never have to write a line of Perl code...
In all fairness, those examples aren't very Perlish. The author has
attempted to write C++ in Perl. Ewww. From Cole's talk on Myghty, I
know that one can also write Perl code using Python. Trying to force
one language's design principles on to a language with very different
design principles usually results in ugly code.
Perl isn't a "pretty" language. Perl is fundamentally an
amalgamation of C and Unix shell tools (sh, grep, sed, awk, etc.). In
that context, coming from that background, Perl seems very familiar.
If you don't already know all those tools, though, Perl doesn't make
much sense. So a lot of it depends on background.
Of course, Cole says they're already using Perl. That implies that
they at least know Perl. (One hopes.) They may even find Perl makes
sense, if they have the background. A better question is "Why are
they using Perl?" Is it because they're working with Unix shell tools
and doing a lot of text file parsing? Or is it because they already
knew Perl? If it's the former, that's a good argument for Perl. If
it's the later, it's worth at least considering (re)training.
Of course, given the background in Perl, one must make sure the
(re)training is comprehensive. Using Python to write Perl code gets
you the worst of both worlds. This is why (re)training is so
expensive, and why many opt to use what they know best. It's a tough
decision to make, and requires more then a little prescience to make
A lot of the links I've read complain that Perl is
unreadable/unmaintainable/etc. I find these comments rather
subjective. Beauty and the eye of the beholder and all that.
Further, many of the "proofs" I see put fourth for this usually assume
either incompetence or deliberate intent. (Linking to the the
Obfuscated Perl Contest... gee, you'd think the name would give it
Perl is sometimes criticized for being "too concise". One could as
easily criticize Python for being "too wordy". Or maybe Python is
"too concise" when compared to COBOL. Again, these are subjective,
and rather arbitrary criticisms.
It doesn't reflect well that these are, for many, the primary
objections to Perl. It's akin to bitching about the use of whitespace
as syntax in Python.
Here are some *real* objections:
Perl sucks at complex data structures. If you need to parse a text
file, Perl is great. If you need to model a real-world system, ick.
Building structures with references is work one shouldn't have to do.
You have to take the time to build the reference structures, and the
time to decode them. Because Perl doesn't really "know" about your
data structures, it cannot do any error checking on them. It's akin
to working with pointers in C. It's easier to debug, since instead of
a segfaults, you see Perl reference fruitcake (instead of the data you
wanted), but you shouldn't have to do all this in the first place.
The OO system in Perl is bolted on at best. It's too heavyweight
for quick things. It's more worth it for complicated things, but
still requires a lot of extra work on the programmer's part (because
it was hacked in using Perl's existing features).
Structured exception handling, while sort-of possible in Perl,
doesn't seem to get used as such. You can make any built-in function
die ("throw an exception") easily enough (with "use Fatal"). You can
wrap code in eval blocks to trap errors. But I don't see that done
much. I generally see the more traditional in-line error checking.
This tends to clutter code, of course. I haven't worked with "big"
Perl programs, so maybe it gets used more there.
More information about the Python-talk