Python Productivity Gain?

[beliavsky at aol.com]

claird at lairds.com (Cameron Laird) wrote in message news:<1039hhilrs4rb5 at corp.supernews.com>...

> These are good points to raise.

Thanks for your informative reply. 

> 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.

If you are willing to spend the time to learn it, a subset Fortran 95
language called F is free for Windows, Linux, and other platforms --
see http://www.fortran.com/F . A project to create a full Fortran 95
open-source compiler is well underway and may be completed this year.

> 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".

It's not just float vs. int. Below is a very simple illustration --
code to compute the standard deviation of a set of numbers, in Fortran
95 and Python. In the F95 code, it is clear that
(1) x(:) is a 1-d array of real's that will not be changed inside the
function (note the intent(in))
(2) the function returns a single value (F95 functions can return
arrays and structures, if they are declared as such).
(3) the function has no side-effects because it is declared PURE.

In the python code, all you know is that sd() takes one argument. It
could change that argument or some other global variable. It could
return a scalar that is real, integer, or something else. It could
return a list, a 1-D Numeric array, a 2-D Numeric array etc.

pure function sd(x) result(value) 
   ! compute the sd of a vector 
   real    , intent(in) :: x(:)
   real                 :: value
   integer              :: n 
   real                 :: xmean
   n = size(x) 
   value = 0.0 
   if (n < 2) return
   xmean = sum(x)/n
   value = sqrt(sum((x-xmean)**2)/(n-1.0))
end function sd

def sd(x):
    """ compute the sd of a vector """
    n = size(x)
    if (n < 2): return -1
    xmean = sum(x)/n
    return sqrt(sum((x-xmean)**2)/(n-1.0))

In this case, and for other numerical work, I prefer Fortran 95 to
Python, even ignoring speed advantages and the advantage of an
executable over a script. F95 can look a lot like Python -- no curly
braces or semicolons, and a lack of C/C++ trickery in general.

Of course, Python and other scripting languages were not primarily
designed for numerical work. Numeric Python is powerful and elegant.

Another point. Python advocates often claim it is better than compiled
languages because the code is much shorter. They rebut worries about
the loss of safety by recommending unit testing. In a Fortran 95 or
C++ program, I don't think as many tests need to be written, because
the compiler catches many more things. If you include the amount of
testing code when counting the amount of code needed, I suspect
Python's brevity advantage will partly disappear. Also, I regard unit
tests to check what happens when a Python function is called with
invalid arguments (int instead of float, scalar instead of array) as
low-level, tedious work that I would rather delegate to a compiler.
Scripting advocates claim that their languages are higher level than
compiled languages, but in this case the reverse is true -- the
compiler does more work for you than the interpreter does.