New to Python: Features

[Alex Martelli]

<beliavsky at aol.com> wrote:
   ...
> Were you using Fortran 77? Most of this version's limitations (rigid
> source form, no abstract data types, no dynamic memory allocation, no
> compile-time checking of procedure calls) were fixed in Fortran 90.

Although, during the '90s, I did lead several pilot projects to evaluate
alternative language possibilities for my employer of the time, I wasn't
the one tasked with the Fortran 90 evaluation pilot projects -- if I
recall correctly, the CTO himself, a staunch Fortran lover, rolled his
sleeves up and did the technical-leading himself for those; I was only
involved in the mop-up/assessment post-project phases.  By the time F90
compilers were mature, we were comparing against C++, and F90 came up
short.  Not sure what you mean by saying F77 had "rigid source form":
Fortran IV did, but F77 allowed leeway.


> . G95 is still under development, but it does compile a wide range of
> production codes, some listed at http://www.g95.org/g95_status.html .

As I mentioned, I and many others regularly use pyrex in production,
too.  By directly attacking pyrex as "not mature", yet recommending G95
as the open-source Fortran compiler without (in your previous post) even
a _mention_ that it's in a state strictly comparable to pyrex, I feel
you were being utterly unfair, some migth even say dishonest.  In both
cases (definitely so for pyrex; for G95 as well as I can divine, given
its huge, rambling, disorganized, nigh-unreadable pages) the main issue
is that not all language construct are fully implemented yet -- for
example, in Pyrex, you need to spell incrementing as
    x = x + 1
because Greg hasn't yet gotten around to implementing the terser syntax
    x += 1
and presumably Greg won't want to tag Pyrex as "1.0" until he has.  (And
G95 pages also mention the fact that some corners of the language are
not implemented, though I was unable to find clear and complete docs).

As long as the docs are clear, explicit, and readable about this, the
lack of some language construct need not stop you from using a tool in
production, the way crashes or bugs in code generation might (unless
your problem is such as to _need_ a missing construct, of course: if so,
then the fact that the construct is in the language but not implemented
in the tool is equivalent to the construct missing from the language, as
far as using that particular tool is concerned).

 
> My general argument is that Python advocates are attacking a straw man
> when they talk as if the main alternative to a high-level modern
> language like Python is good old C.

In many application areas, that _is_ the case: people are using lower
level tools such as C for a variety of reasons (I have already
recommended Raymond's "Art of Unix Programming"...).

> If they compare Python with C++
> with OOP and STL for general-purpose programming, or with Fortran 95
> for scientific computing, some of the "high-level" advantage of Python
> disappears.

I am familiar and experienced enough with C++ with OOP and the standard
C library (I don't know why people keep confusing that with a research
endeavor like SGI's STL: while STL was a crucial model for C++'s
standard library 10+ years ago, they are not the same thing -- if you're
looking for nonstandard C++ add-on libraries, Boost is preferable) to
address this part of your "general argument" knowledgeably.  Sure, if
C++ with all the trimmings is higher-level than C (and it is!), though
not quite as high-level as Python, then, tautologically, _some_ of the
level difference does go.  In terms of SLOCs per function point, the
definition of "language level", C may need 128, C++ 53, Python 21 (these
are Capers Jones' tables: he does not have Python there, but he does
have Perl and Python is quite similar levelwise).  So, the Python
advantage would be 6 times over C, but just 2.5 times over C++ (Fortran
77, 107; Fortran 95, 71; so Capers Jones is claiming these are higher
level than C but not nearly as high-level as C++).

(( Feel free to disagree with the tables -- I do, in many details -- but
at least they're a basis for discussion, and while the numbers are far
from perfect they's never off by as much as, say, a factor of 2.
Differently from heavy users of most other languages, heavy users of
Python do have vast experience rewriting production-level code from
other languages into Python (to gain flexibility and merge snippets
coming from elsewhere), and from Python into other languages (C, C++,
Objective C, Fortran, pyrex, Java), for optimization and contractual
obligations (some programming shops have contractual demands to deliver,
say, Java language sources: they do all their early development in, say,
Jython, then gradually recode each component in Java, with a working
system and solid unit, regression and system tests at each step -- it's
more productive than coding in Java right off, they judge).  This
practice, we feel, makes us pretty good judges of SLOC ratios between
Python and other languages, depending on kind of application, etc. ))

The advantage of going to Python, rather than C++, for a C programmer,
is that, while in Python he's going to find very different syntax, and
(like Java) different semantics of assignment statements, in Python he's
actually going to be operating under a _philosophy_ that's very close to
the one that made (and still makes!) C such a roaring success: trust the
programmer, don't stop the programmer from needing what needs to be
done, offer only one way to perform an operation, etc -- in fact, 4.5
out of the 5 points that the ISO C Standard identifies as "The Spirit of
C" (the point about speed/portability tradeoffs is the only one that
Python only meets about halfway).  People who detest that philosophy
will of course detest Python as much as they detested (and still detest)
C.  And yet Python proves that you can get a 6:1 language level ratio
(according to Capers Jones; much more, according to Pythonistas' vast
collective experience) _without_ abandoning simplicity and flexibility,
indeed _increasing_ those characteristics, and dynamicity too.


So: Python's language level is very high, and getting higher with such
innovations (wrt the time Capers Jones wrote his table 8 years ago) as
generators, type/class unification, custom descriptors and metaclasses.
Frameworks such as Twisted, Numeric, scipy, effectively increase that
level in important application areas (like Boost &c can do for C++).
The claim that very high level programming _combined_ with simplicity,
flexibility, and all the other good things above mentioned, is a huge
boost to productivity, keeps getting real-world confirmations.  And the
wonderful ease of interfacing Python, perhaps with pyrex help, to codes
and libraries in a huge variety of other languages, is crucial.  You
mentioned C++ and F95: I would not be surprised if the best _portable_
(across compilers and platforms) way of using both C++ and F95 in the
same program would be exactly to interface each of them to Python!-)


Alex