Python vs. Perl, which is better to learn?

[Terry Hancock]

From: geek <geek+ at andrew.cmu.edu>
 Organization: 
> Then <aaovlj$agm$1 at bubba.NMSU.Edu>, spoke up and said:
> > Bob Melson <"melsonr at earthlink.net"> wrote:
> > >Kinda hard to say.  In general, however, I'd say that _I_
> would be inclined
> > >to use perl in preference to python where there's no
> significant advantage
> > >to be derived from python's OO features.
> > 
> > Can you provide a non-contrived example, given that you're
> attempting to
> > advise someone who knows neither Perl nor Python?
> 
> My rule is simply: if there's no good reason to use !Python, use
> Python.  Now, what's a good reason not to use Python?

I've got practical examples:  I sometimes use Perl as a
"super-sed".  The original sed's REs are getting quite
out of date, so it's kind of nice to use Perl's.  Doing
the same thing in Python is quite feasible, but will probably
take about an hour longer to make work, because you have
to get the import right, compile the regex and figure out
how to get data in and out of the program. All easy stuff,
but extra lines of code, and if you're thumbfingered with
the RE module it takes some time to get right.

If the project was going to take five minutes to write in
Perl, then that's about 1200% overhead.  Particularly
nasty if the lifetime of use is another ten minutes.

In developing a web app in Python/Zope I needed a bunch
of image-buttons. They are color coded -- or rather
color-scheme coded because they are anti-aliased.

I used ImageMagick's convert to pipe the GIFs out to an
XPM which is a readable, palette-based format (open it
in gvim if you want to see a cool example of syntax
highlighting).  Anyway, I can easily use a regex to
swap the color patterns around in the palette, e.g.:

perl -pe 's/(00)([0-9a-f][0-9a-f])00/\2\2\1/' green.xpm > yellow.xpm

(Now loop that over a couple hundred files, either in Perl,
or as I did, using tcsh's foreach. Then change colors and
loop again.).

That would've taken a bit longer in Python, and it's doubtful
I would recoup the investment (though I probably spent more
on this email ;-D ).  It's not foolproof -- it won't catch
named colors, for example, only numerical ones.  But it
was good enough and fast enough.

A slightly less trivial example was a problem in which my
partner had recorded a bunch of business transactions in
a comma-separated list in what turned out to be the wrong
order. She wanted to flip everything around and compute
sums over it. We aren't planning on standardizing on this
format or anything -- we just haven't gotten a spreadsheet
or database solution that works for this yet.  April 15th
was pressing and we just needed to get the stats ready for
it (this is the Income Tax deadline in the US).  I spent
about 30 minutes and got the output to work using Perl.
It was not particularly elegant, but only took about 
10-20 lines of code. It was highly dependent on observable,
but unintended coincidences in the data, such as the
use of metric date order which causes string sorts to
be equivalent to date sorting.  It was however, noticeably
faster than computing it all with a hand-calculator. It
was also a good decision, since we actually had to alter
it 3-4 times to get the correct answer (this would've
taken 2-3 hours on a calculator, because the entire
process would have to be repeated).

The same thing would've taken me 3-4 hours in Python
and about 40-50 lines of code. I would have had a much
nicer program though -- one I'd have been able to
incorporate or make permanent if I needed to. If we
were even considering standardizing on data like this,
I'd have used Python.

It seems to me that (with considerable training overhead)
Perl allows you to make these extremely short utterances
of code which do very clever things, do them quickly,
and with little development time (e.g. on the order of
the single usage time, as above). On the other hand,
it doesn't analyze well.  I probably won't remember what
exactly I did when tax time comes next year, and the
coincidences that the above code depended on may not 
be there.  On the other hand,  by then I won't need it
anymore, because the data will be in a different format.

This is what I meant by "duct tape role" in my previous
posting.

On the other hand, if I'd never learned Perl, I could
probably do all of the above in Python. But I might've
opted to just do it manually in some cases. That would've
been a loss, though, as I would actually have underestimated
the cost of doing it manually in both of these examples
(both times I expected to get it right the first time,
but actually repeated it 3-4 times until I was satisfied --
at a cost of only a couple of minutes for each retry,
since I had used a program).

The problem of course, is that this kind of underestimation
happens a lot. In particular, a program you write to
solve one problem is frequently one you realize later
would be useful for something else. And then you want
to add stuff to it. With Perl this would get you into
trouble quickly, whereas Python encourages you to use
more sensible design and you usually wind up with something
you *can* reuse.

My biggest argument for Python though, is that it is
the only language I can program in while being interrupted
by small children!  I don't know why, though I theorize
that it's because of the explicit readability, but I
can "recover state" much faster with Python than with
any other language I've tried (including, but not limited
to Perl), which generally require me to maintain very
high levels of focus to code.

When you're being interrupted every 1-5 minutes by a 
diaper emergency, spilled oatmeal, or urgent reports from
"Planet Iima", this becomes a non-trivial concern. If
it takes you typically 5-minutes to recover your focus,
it can quickly be seen that your productivity will plummet
to near zero, while if you can recover in 30-seconds or
so, you'll be at 50-90% efficiency, which is not too
bad.  I assert that this environment is the severest
test of mental discipline you can go through! ;-D

Good for the soul, though, I suppose, and better than
not programming at all.

-- Terry

DISCLAIMER:
I have made every effort to ensure that there are no
objectively-verifiable statements in the above (any
seeming objective statements are hereby declared
bogus and void), making this entire communication
subjective, and most emphatically, IMHO. ;-D
Personally, I think the whole issue is aesthetic
and subjective, and I might like to make the assertion
that it is rigorously impossible to be otherwise. But
I'll leave that to the philosophers!

-- 
------------------------------------------------------
Terry Hancock
hancock at anansispaceworks.com       
Anansi Spaceworks                 
http://www.anansispaceworks.com 
------------------------------------------------------