Python vs. Perl, which is better to learn?

Peter Hansen peter at engcorp.com
Wed May 8 01:07:23 EDT 2002


"James J. Besemer" wrote:
> 
> Peter Hansen wrote:
> > Patrick W wrote:
> > > I *was* thinking that there are many situations in which Python is too slow ...
> >
> > I object to that characterization: in two years
> > of extensive Python use in a very wide variety of areas, I have not
> > yet found Python to be "too slow".  I believe this is a common myth
> > or nasty rumor, without strong basis in reality.
> 
> A lot of real-world applications require performance approximating the 
> underlying CPU speeds

Disagree.  A lot of real-world applications may say that, but in fact
they simply need some fixed but often unspecified performance and 
they might have chosen a slower CPU than they should have.  Few projects
are based on adequate analysis of the relative costs of a bit of 
faster hardware versus a longer development cycle.  For mass market
hardware, clearly cost of hardware rules.  For custom/one-off projects 
<warning reason="blanket statement"> much faster hardware combined with 
Python would be a far better choice than slower/cheaper hardware 
and a solution in C </warning>.

> ...in which case Python would be simply unable to do the job.  

Well, with a slow enough CPU, any language may be inadequate.  Contrariwise,
with a fast enough CPU, Python can certainly be fast enough for the job.
What project have you seen where the requirements said "must run as
fast as can possibly be achieved, at all costs, regardless of choice of
implementation language, duration of project, or other concerns."
I'm sure there are some close to that, but they are not widespread
and don't justify the "there are many situations" claim.

> There are other real-world applications where the hardware is too cramped for a
> language as "cushy" as Python.  [...]  A further example is the millions of extremely
> tiny CPUs being deployed.  E.g., one project had a CPU that lived in a hand-held
> probe.  

Well please, let's stick to reality-based discussions.  Obviously there
are places where Python simply won't fit, so discussing whether it
is fast enough (that was the topic) in those applications is pretty
meaningless.

> For less time critical applications, like serving up CGI or preparing reports or
> other sys admin functions, Python surely is plenty fast enough.  But it's wrong to
> extrapolate your limited experience in that domain to all or "many" other situations.

I'll assume you meant "your limited experience" in the sense of my having 
none at all in that area.  I've never used Python for such tasks and I wouldn't
make the mistake of extrapolating from such limited experience, I believe.

I have, however, used Python in a number of other areas including:

 - web applications (Zope, with an Intranet running on basic hardware serving
   a company of 100 people), where response time is important

 - automated factory test (controlling RF equipment via GPIB, serial, and 
   CAN interfaces and providing a GUI and an output stream in XML), where
   total test time is critical to factory production rates

 - embedded control and monitoring (running on 386 and 486 chips on PC104 
   boards with from 1MB to 32MB RAM and flash memory, monitoring and 
   controlling dozens of external devices via a triple CAN interface),
   where scan rates are important (soft realtime) and bandwidth matters
 
 - basic sys admin utilities (wow! so I do have some experience there... 
   go figure), where generally speed is quite unimportant

 - probably a couple of other areas I've forgotten.

Perhaps this /is/ limited experience from which to draw conclusions...

> If I may offer a personal observation: It kills me when someone's strongest 
> argument that something simply cannot be is that he "hasn't seen" or 
> "can't think of" any contradictory data.  Just because you can't THINK of 
> it is usually NO grounds to object.

Ohh... you must have misread my comments.  Please go back to the top
and find where I said that I objected to the claim there were "many
situations where Python is too slow", not what you say I said, which 
is apparently more like "Python is never too slow".  Just because you THINK
I said something doesn't mean I ACTUALLY said it.

For the record, and since you must have missed the past discussions on
the topic, there /are/ places where Python has been reported to be too slow
and I'm aware of them.

I just haven't encountered any myself (as I said) and I object to the 
statement that it will /often/ be the case that it is found to be too slow.
I believe quite the opposite, if it wasn't clear: it will /rarely/
be the case that Python is found to be too slow.

'Nuff said?

-Peter





More information about the Python-list mailing list