Python versus Perl ?

[Adam DePrince]

On Tue, 2005-02-08 at 22:44, Caleb Hattingh wrote:
> Hi m
> 
> Speed is a contentious issue here.  Point is, if you really need raw  
> speed, why stop only at Perl and Python?  There are plenty of statically  
> compiled languages that will produce native binaries.
> 
> The relative difference in speed between Perl and Python, whatever it is,  
> is completely washed out by the enormous jump using, say, C for example  
> [please, everyone else, I am aware of all the mitigating circumstances  
> regarding, e.g. parts of the standard library written in C, etc.  That is  
> not my point.]

I think the expression you seek is "comparing virtue among whores."  

Now we can all acknowledge that there is a spectrum in the programmer
time vs machine time trade-off.  (Voice reader users: Please forgive my
ASCII art ... imagine a data set that loosely fits a linear relationship
with a negative slope.)

ASCII art start 

 +
M|*
A|  *  *
C|    *
H|     *         "STUPID"
I|   *     *
N|      *
E|          *
 |             *
C|                 * *
O| "Holy             *
S|  Grail"           *
T|                      *
 0------------------------- +
   PROGRAMMER COST

ASCII art stop

This metric is actually in two dimensions, but we usually consider it in
one dimension with High Machine cost and low programmer cost at one
extreme and low machine cost and high programmer cost at the other
extreme.

ASCII art start

High Machine  <---------------> High Programmer Cost

ASCII art stop

because there is a high inverse correlation between programmer and
machine costs.  Only a fool would use a programing language in the
"stupid" area of the above chart (both costs high).  Likewise, nobody
gets to use the language that does not exist in the "Holy Grail" area of
the chart (both costs low.)

Both Python and Perl are way up in the upper left ( machine cost high,
programmer cost low) of my little chart.   Perl has much magic that
drives up its programmer cost.  Not by much in the know, but by enough
that I would consider it to have a slightly higher programmer cost than
Python.  If Perl code executes a bit faster, then fine, all I can say is
"that's nice."  If machine costs were an issue I'd recode in vhdl and
compile to silicone.

Of the topic I want to address,  you can entirely circumvent those
issues by coding in C and using the Python C-API instead of strcmp and
friends.



> 
> A Good Reason for thinking along these lines (Perl/Python) is more  
> something like speed and reliability of development.  Another one is  
> maintaintability.  I must confess that I know pretty much nothing about  
> Perl, so I can't comment about that.  My opinion about Python is that it  
> is very, very good for these things.
> 
> The problem domains in which I do most of my work (chemical process  
> modelling and simulation) really do require speed.  That's why I mostly  
> use Delphi (i.e. reasonably fast code) at work.   I believe I know when  
> speed is and is not an issue, and (by far) most of the time, my experience  
> is that it is *not*.  So I use Delphi for numerical code and python for  
> everything else.

Why don't you use C for the numerical work?  Then you can do your number
crunching within a c-based python module.  Have your cake and ... 

> 
> You really will have to convince people here that execution speed is a  
> real issue for your programming task (in order to continue this  
> discussion).  Otherwise the debate will go south real quick.

Not only most speed be an issue, but the economics must be such that any
alternative is better than throwing more hardware at the problem.

Adam DePrince