Python vs. Perl, which is better to learn?

[James J. Besemer]

Terry Reedy wrote:

> Hi James,

Howdy!

> Thanks for the report from current real-time computing battlefronts.
> My only direct real-time experience was writing an analysis program
> for radiation counts that arrived in batches of three once a minute.
> I wrote in Basic for a Kaypro connected by a 300/1200 baud serial
> line.  Worked fine.  But I understand that things now are often (but
> not always) quite different.

My only point is there's a spectrum of economic and technical solutions
and there are important application domains on the high end where Python
probably is not fast enough.

> Peter's concern about myth-mongering comes from the following type of
> exchange:

I very much appreciate this but his reply was overly simplistic to the
point of error in insisting that it's almost never a problem.

> The point which underlies Python but which excapes some is that faster
> and faster CPUs change the ratio between programmer cost and CPU cost
> in favor of using more CPU cycles.

Absolutely.  No question.

Today's computers are faster than ever.  Many times I approach a problem
with a straigh-forward solution, half-expecting it to be too slow (in
whatever language I am using) and I usually find that performance is not a
problem.

After posting my missive, I got to wondering, will there ever be a day
when CPU horse power is so inexpensive and readily available that this
ceases to be an issue?  I dunno.  Maybe.  I recall that on Star Trek, the
computer responds instantly to most requests, including massive, realtime
3D holodeck displays.  Then too, IIRC, from time to time they pose a
problem where the computer takes a while to answer.  Seems to me there'll
always be some combnitorial problems where that excess speed is worth the
extra effort.

> -- And yes, there will *always* be new or extended leading edge
> applications that will sop up every cycle available.  For them, the
> only use for Python is (maybe) as a prototyping language for exploring
> alternative algorithms.

Seems patently obvious.

An anciliary application I've found in domains like this is analyzing
reports.  You run the system and it generates megabytes of trace data.
Then, after the fact, you scan the report for patterns and to calculate
statistics.  This is a job for Python, not humans.

I must confess there are times where it actually (in all honesty) takes me
longer to write the tool than it would have taken to do the job once
manually.  I arguably would have done better by my client if I didn't
write the tool.  But I'm lazy and can't stand tedious, repititious tasks,
so usually, if I can think of a way to automate then that's the plan.

Regards

--jb

--
James J. Besemer  503-280-0838 voice
http://cascade-sys.com  503-280-0375 fax
mailto:jb at cascade-sys.com