Python Productivity Gain?

[Cameron Laird]

In article <3064b51d.0402181326.1b046f29 at posting.google.com>,
 <beliavsky at aol.com> wrote:
			.
			.
			.
>My main other language is Fortran 95. For simple text analysis or
>"database" programming (sorting a list, merging two lists etc.),
>programming in Python is much faster, since more functionality is
>built-in and the code is generic. If you write a sorting routine in
>Python, it will work for lists with any type of elements (int's,
>real's etc).
>
>For numerical work, I still prefer Fortran 95 to Numeric Python.
>Genericity is not as important here, and in any case a single Fortran
>95 code can be written to do a calculation in single, double, or
>quadruple precision, using the KIND feature. Fortran 95, properly
>used, is safer than Python, because (for example)
>1. function interfaces are checked at compile time
>2. constants can be declared
>3. the DO loop is more restrictive -- the looping variable cannot be
>changed inside the loop
>
>Well-written numerical F95 code is clearer to me than comparable
>Python code because one can specify what input arguments of a function
>will not be changed (using the INTENT(IN) feature) and what the
>dimensions of all arguments are. It's also clear from reading the
>declarations what the function is returning, whereas a Python function
>can return anything, depending on how it is executed.
>
>There are several independent implementations of languages like C++
>and Fortran on both Linux and Windows. I don't think this is true for
>Python. They create stand-alone executables that don't require an
>interpreter on the target computer. Their language committees are
>unlikely to make changes that break old code, as the prospective
>change in Python's integer division will do.
>
>I do like Python, but no language is a panacea. I think Python should
>add some OPTIONAL safety features.

These are good points to raise.

Fortran's my first language.  I have little opportunity nowadays to
exercise it, much as I'd like to do so.  I'm certainly not as current
with it as you.

When I read, "It's also clear from reading the declarations what the
function is returning ...", I take it that you have in mind such 
distinctions as FLOAT vs. INT.  Reasoning about types is a *frequent*
topic of discussion in comp.lang.python.  I'll summarize my experience
this way:  FLOAT vs. INT (and so on) takes little of my day-to-day
attention.  I focus on unit tests and coding which is semantically
transparent in a more comprehensive way than just type-correctness.
Therefore, while I acknowledge the advantages you describe for Fortran,
I categorize them mostly as, "no big deal".

There are a few other factual clarifications I hope I can contribute.
Perhaps most important is to recommend "dual-level" programming; it's
eminently feasible to *combine* Fortran and Python.  I think of language
choice in a connected, rather than discrete, space; my alternatives
are not 1.0 Python vs. 1.0 Fortran, but 1.0 Fortran vs. (0.6 Fortran,
0.4 Python) vs. ...

While there's only one "independent" implementation of Python, in the
strictest sense, it's frankly impressive how many *distinct* implemen-
tations there are <URL:
http://phaseit.net/claird/comp.lang.python/python_varieties.html >.
In particular, I think you'll have an interest in the performance-
enhancing Psyco and the "compilers" which produce stand-alone 
executables.  Perhaps you hadn't encountered them before.

No language is a panacea, indeed.  Python comes remarkably close,
though.
-- 

Cameron Laird <claird at phaseit.net>
Business:  http://www.Phaseit.net