Python vs. Perl, which is better to learn?

[brueckd at tbye.com]

On Wed, 1 May 2002, Terry Hancock wrote:

> > 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

An hour longer!? 

>, because you have
> to get the import right

import re, sys  # Time: 2 seconds

>, compile the regex

myRE = re.compile(RE_STR) # Time: 3 seconds

> and figure out
> how to get data in

data = sys.stdin.read() # Time: 2 seconds

or

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

# Time: 6 seconds

> and out of the program

print whatever # Time: 1 second

> All easy stuff,
> but extra lines of code, and if you're thumbfingered with
> the RE module it takes some time to get right.

The only meat left is to figure out the RE_STR, whose syntax will be
pretty close to Perl's. So, by your estimate I have about 59 minutes and
50 seconds not to figure out RE_STR, but simply figure out how it would be
different from the Perl version. Or, if I already know the Python re
syntax, I could just write the re, and I have a decent chance of finishing
in about the same time as it would take to write the Perl version.

My sample code may seem too contrived, but the
read-input-perform-sedlike-processing-and-dump-it problem is pretty
common, and I guarantee that it just doesn't take an hour longer than a
Perl version to wade through that "overhead". It really is on the order of
seconds, if that.

> 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.

A counter-example: I don't remember Perl that well, and a sed-like program 
would take me 5 minutes to do in Python. Because my Perl skills are so out 
of date, it'd take me TWO HOURS. That's 2400% overhead! <0.1 wink>

[snip]
> 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.
[snip]
> The same thing would've taken me 3-4 hours in Python
> and about 40-50 lines

All of your examples point to the fact that you're more comfortable with
Perl than Python, and that's fine, but the exact opposite results can be
found if a person is more comfortable with Python than Perl; this has
nothing to do with whether or not the language is worth learning or using
though. There will be times when doing it in Perl is a little faster, and
vice versa, but claiming even a hundred percent gain in favor of Perl is
pretty FUD-like, IMO.

> 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)

I find that the same is true with Python, with perhaps lower training 
overhead. We routinely use it for one-off programs and utilities, and 
literally *never* have one-offs requiring development that you'd measure 
in hours. That's preposterous. If Perl works well for you on throw away 
stuff, stick with it, but you're kidding yourself if you think that Python 
has some inherent development overhead that is going to make more than a 
few seconds difference.

Have fun,
-Dave