Python is far from a top performer according to benchmark test...

[Samuel Walters]

|Thus Spake Lothar Scholz On the now historical date of Fri, 09 Jan 2004
21:29:56 -0800|

> Samuel Walters <swalters_usenet at yahoo.com> wrote in message
> news:<pan.2004.01.09.21.35.40.132608 at yahoo.com>...
> 
>> For numerical processing, C is the right tool,
> 
> Definitely not, you don't want a pointer language when using numerical
> processing: use Fortran.

Hmm.  I feel misunderstood.  I'm going to try to clarify, but if I'm the
one doing the misunderstanding, feel free to give me a good old-fashioned
usenet style bitchslapping back to the stone age.

First off:  Truth in advertising.
I know very little about numeric processing, and even less about Fortran.
It's true that my background is in mathematics, but in *pure* mathematics
where pointer-based languages tend to be helpful, not hurtful.  I chose
pure mathematics precisely because it eschews the grubby sort of shortcuts
that applied mathematics uses.  In other words, I didn't have the proper
sort of mathematical intuition for it, so I chose pure, where my kind of
intuition works well. (In the end, this was to my detriment.  All the
interesting problems are in applied math!)

As I see it, when one considers which language is best for one's needs,
one considers a couple of things:

	1)  Does the language have the semantics I want. 
	2)  Does the language have the primitives I need. 
	3)  Can I *easily* build any missing or	suboptimal primitives.

One would assume that Fortran has the proper semantics for numerical
processing because it seems to have been wildly successful for a long
period of time.  It would appear that Python has the proper semantics for
numerical processing because a significant number of people are using it
for that, and they'd be using something else if Python caused them too
many headaches.

Fortran naturally comes with the primitives for numerical processing,
because numerical processing is its stated goal. ("FORmula TRANslation") 
Python doesn't seem to have the native and optimal primitives for
numerical processing, so that leads to point three.

Whether one uses Fortran, Python, or any other language, all primitives
are eventually implemented in either C or assembly.  At some point or
another, we end up scraping bare metal and silicon to get our answers.  
The question then becomes, "How easily can I extend this language to fit
my needs."  NumPy is evidence that at least a few people said "Easily
enough."  I don't know how extensible Fortran is, but I would guess "very"
since I've heard of it being applied in many domains other than numerical
processing.  (OpenFirmware, for example.)

So, I guess that my point is that C might not be the right language for
doing numerical processing, but it seems the right language for
implementing the primitives of numerical processing.  Those primitives
should, of course, be designed in such a manner that their behaviors are
not muddied by pointer issues.

Moving on:
I think Python's strength flows from the three criterion for choosing a
language.  It's semantics seem to naturally fit the way a programmer
thinks about problems.  All the algorithmic primitives are there for
naturally expressing one's self easily.  Where the primitives don't exist,
it's easy to bind outside primitives into the system seamlessly.  One of
the joy's of python is that c extension libraries almost never feel bolted
on.  They feel like an intimate part of the language itself.  Part of that
is the blood, sweat and tears of the library implementors, but much of it
is also the elegance of Python.

As far as the straw-poll goes, I think it's a good question to ask, and
that the answer is important, but we also need to figure out where else we
can ask this question.  The problem with asking such a question solely on 
c.l.p is that everyone here has either decided that optimization in python
isn't enough of an issue to bother them, or hasn't made up their
mind yet.  Those who have decided that optimization in python is a problem
have already gone elsewhere.  Perhaps a better question to ask is "Who has
decided that Python is too slow for their needs, what prompted that
decision and are the issues they had worth addressing?"

Sam Walters.


-- 
Never forget the halloween documents.
http://www.opensource.org/halloween/
""" Where will Microsoft try to drag you today?
    Do you really want to go there?"""