Re: Python vs. Perl vs. C++

Jeffrey Templon (templon@paramount.nikhefk.nikhef.nl)
Tue, 3 May 1994 04:14:45 GMT

In <2q3kea$o96@agate.berkeley.edu> anders@garnet.berkeley.edu (R. Anders Schneiderman) writes:

>2) How much of advantage does it provide over Perl or C++? How much
>faster can you write a moderately complex application, and how much
>eaiser it is to maintain? The Smalltalkers I know have been able to crank
>out applications in half to a quarter of the time it would take them in C,
>and now that they're reusing huge amts of code, they're getting even

I can't tell you about Perl and C++, but I can tell you about
nawk and Fortran-77 (!!) since I've done a LOT of programming
in these two languages.

I've recently written a program to calculate reaction rates in
an experiment we're doing here. It was quite complicated, since
there were lots of things that had to be done: you have to do
relativistic kinematics, you have to convert positions of your
detectors in the laboratory into spherical-polar coordinates
in able to do the kinematics, you have to do lots of coordinate
transformations since the frame in which you can calculate
the reaction rate is very different from the one used to
describe the experimental setup (positions of the detectors),
etc. etc.

My experience with Python has made me look less at this as a
program, more as a "software system" to do a certain set of
tasks. Once you have certain things programmed in, it
becomes EXTREMELY easy to reuse these things for other tasks.
For example, in writing the kinematics part, I chose to write
a general class, "four vectors" (a fancy way of specifying the
mass, velocity, direction and energy of a particle.) I
had to write another kinematics routine shortly thereafter:

import fourvec

was one of the first lines. I wrote the coordinate transformation
routines so that they could operate on members of "class Fourvec".

I also find myself now running python programs as "python -i prog";
then you can keep going with the basic set of things that
were calculated in "prog". I often have functions return
"dictionaries" which contain a sort of table of all info
calculated in the function; you can ship this dictionary around
from place to place in your program with almost zero effort
compared to a traditional language.

For example, this reaction-rate program calculates a rate
averaged over a certain part of our apparatus. I wrote
a function which calculates the rate for each one of the
400 pixels on the detector, and summed the result over
the pixels of interest. Later someone asked me to
calculate the integrated rate over the whole detector. Piece
of cake. Later somebody wanted to know one of the kinematical
quanitities for each pixel on the detector. I had the
rate-calculating pixel function return a dictionary
which included all the kinematics info ... thus I had
dictionary of dictionaries:

pixel_info = detector_info["pixel_name"]
pixel_info["rxn"] = < two body kinematics info for this pixel >
pixel_info["dk"] = < decay kinematics info for this pixel >
pixel_info["rate"] = < reaction rate for this pixel >
...

Things like "rxn" are also Python structures; for example
"rxn" has four attributes which are the four-vectors for
the two initial and two final reaction particles.

I've babbled enough, I hope the technical jargon isn't too
much.

JT