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

[David M. Cooke]

Okay seems that you don't know a lot about compiler writing.

A C compiler only knows a little bit about the context so it must
always assume that a data inside a member can be referenced from
another place via an alias pointer.

Fortran does not have this problem so a lot of optimizations can be
done and values can be hold in registers for a much longer time,
resulting in much greater speed.

Remember that on supercomputers a 25% spped enhancement (which a good
fortran compiler is faster then C) can mean a few million dollars of
saved hardware costs. The coding time is not importing compared to the
running time. So real hard numerics are always done in Fortran.

GNU Fortran is a stupid project because it translates the Fortran code
to C.

Err, no. You're thinking of f2c. GNU Fortran uses the same backend as
the GNU C compiler, in that it translates to the same intermediate
language (sort of assembly language) on which optimizations are done.
But the C front end and the Fortran front end are separate.

The advantage of GNU Fortran is it's *portable*. It runs on everything
that GCC works on -- which is a lot. This makes a difference when
you're developing (like on my Apple iBook running Linux). And it looks
like the G95 project is humming along nicely.

Python for hardcore numerics, even with PyNumerics, is simply a very
bad solution.

You're not limited to pure Python.

No one's saying you must use only C, or only Fortran, or only Python.
Use the best tool for the job. Python just has the advantage that
mixing C and Fortran into it is easy. Write your big, number-crunching
code as a Fortran routine, wrap it with f2py, then add a Python script
around it to run it. Presto, no fiddling with Fortran for reading in
input files, or output files (depending on your routine). You can even
write a GUI in Python if you wish. Or add a webserver.

 

[Jeff Epler]

Python for hardcore numerics, even with PyNumerics, is simply a very
bad solution.

I think that many of us are not in a situation where we have to make our
program run fast enough to save a million on a supercomputer, but where
we have to make our program run soon enough to save a few thousands or
maybe tens of thousands on programmer time.

ObLink: http://cens.ioc.ee/projects/f2py2e/

Jeff

 

[Lothar Scholz]

Err, no. You're thinking of f2c. GNU Fortran uses the same backend as
the GNU C compiler, in that it translates to the same intermediate
language (sort of assembly language) on which optimizations are done.
But the C front end and the Fortran front end are separate.

But the front end is, as far as i know, only responsible for syntax
analysis. All code generation like control flow analysis, register
allocation etc. is done on the intermediate 3 register language. And
the hints you could get from the fortran language are simply unused.

But i must say that i never used Fortran (when i studied physics) in
the last 15 years for any real programming. I only wanted to point out
that a lot of languages are by design faster then C. Fortran was one
of these. You can find articles on the web where the same is explained
for lisp and functional languages.

C and C++ is not a good compilation language when it comes to compiler
optimization.

 

[Robin Becker]

Fortran does not have this problem so a lot of optimizations can be
done and values can be hold in registers for a much longer time,
resulting in much greater speed.

I'm not sure I agree with the above. Aliases could certainly occur in
fortran 77, I haven't used 90 so can't say for sure.

 

[Robin Becker]

That's the magic of Fortran: the F77 standard says (in part):

If a subprogram reference causes a dummy argument in the
referenced subprogram to become associated with another
dummy argument in the referenced subprogram, neither
dummy argument may become defined during execution of
that subprogram.

It bascially says you can alias all you want, so long as you only read the
aliased entities and don't modify them. If effect, if you do anything with
aliases that would inhibit optimizations that assume there isn't any
aliasing, then it's your *program* that's not legitimate Fortran. The
Fortran standard has lots of text "like that", imposing (often unenforcable)
restrictions on conforming programs for the benefit of optimizing compilers.
That was the right choice for Fortran's audience.

this was also my understanding, the difficulty is that humans can't do
the correct analysis in their heads for all, but the most simple
programs. I seem to remember that almost all the compilers I used had
mechanisms for turning off the most aggressive optimisations so if the
card deck suddenly started working with them off then you could try and
figure out what was wrong. Another nastiness was that by putting prints
in you often disrupted the optimisations and the values you got printed
seemed to indicate everything was fine.
-Common blocks are an invention of the Devil-ly yrs-
Robin Becker

 

[Roy Smith]

-Common blocks are an invention of the Devil-ly yrs-

There's no evil you can commit in FORTRAN with common blocks that you
can't do just as well in C with globals and pointers.

 

[Aahz]

That, in my opinion, is wrong: Fortran is successful because it was there
first!

Which brings up the obvious question: why isn't Lisp successful?

 

[Michael Hudson]

this was also my understanding, the difficulty is that humans can't do
the correct analysis in their heads for all, but the most simple
programs. I seem to remember that almost all the compilers I used had
mechanisms for turning off the most aggressive optimisations so if the
card deck suddenly started working with them off then you could try and
figure out what was wrong. Another nastiness was that by putting prints
in you often disrupted the optimisations and the values you got printed
seemed to indicate everything was fine.

This last point is true in C, too, particularly with floating point
code on x86: turn optimization off or put in debugging prints and then
the floats get rounded to C doubles (64 bytes) frequently; don't, and
they stay as 80 bit values in the FPU for longer. This can lead to
differing behaviour (and thus programmer insanity).

Cheers,
mwh

 

[Michele Simionato]

Which brings up the obvious question: why isn't Lisp successful?

But it is successful! Look at people working on AI, theory of programming
languages, etc: they will (presumably) know Lisp. OTOH, look at people
working on number crunching: they will (presumably) know Fortran.
It turns out that the number of people working on numerical analysis (or
using numerical tools) is much larger than the number of people working on
abstract things, so you will have more people knowing Fortran than people
knowing Lisp. But this fact alone does not mean that one language is more
successfull than the other in its application niche. You could compare
Python and Perl (or Ruby) and say that one is more successful than
the other, but Lisp and Fortran have different audiences and you cannot
estimate their success just as number of users.

Just my 2 eurocents,

Michele

 

[Jacek Generowicz]

But it is successful! Look at people working on AI, theory of programming
languages, etc: they will (presumably) know Lisp. OTOH, look at people
working on number crunching: they will (presumably) know Fortran.
It turns out that the number of people working on numerical analysis (or
using numerical tools) is much larger than the number of people working on
abstract things, so you will have more people knowing Fortran than people
knowing Lisp. But this fact alone does not mean that one language is more
successfull than the other in its application niche. You could compare
Python and Perl (or Ruby) and say that one is more successful than
the other, but Lisp and Fortran have different audiences and you cannot
estimate their success just as number of users.

Lest anyone infer that Lisp has an "application niche" consisting of
AI and theory of programming languages ... take a look at

http://www.franz.com/success/

and glance at the column on the left.

I suspect that Aahz' working definition of "successful" had more to do
with success in terms of popularity, rather than success in terms of
technical excellence: please remember that quality and popularity are
very weakly correlated.

If you want to analyze the popularity of a technology, you will get
far better insight by studying the sociological and historical
contexts surrounding it rather then its actual technical merits.

For example, how many readers of this post will be surprised to learn
that (most) Common Lisp implementations compile to efficient native
machine code, that Common Lisp has an ANSI standard which includes
very powerful support for object-oriented programming (to name but two
features that everybody "knows" it doesn't have) ?

Go on, raise your hand if you thought that "Lisp" is a slow,
interperted functional langugage.

You will need to take, amongst many other things, the abundance of
such (non-)facts into consideration, if you want to understand Lisp
lack of "success".

Similarly, the "success" of C++ probably has more to do with having
introduced OOP to the C programmers of the world, that with its
suitability for doing OOP.

--
....Please don't assume Lisp is only useful for Animation and Graphics,
AI, Bioinformatics, B2B and E-Commerce, Data Mining, EDA/Semiconductor
applications, Expert Systems, Finance, Intelligent Agents, Knowledge
Management, Mechanical CAD, Modeling and Simulation, Natural Language,
Optimization, Research, Risk Analysis, Scheduling, Telecom, and Web
Authoring just because these are the only things they happened to
list. -- Kent Pitman

 

[Andrew Dalke]

Jacek Generowicz, quoting Kent Pitman
And as I continue to point out, *Python* is more often used in
bioinformatics than Lisp, and Perl dominates that field, followed
by C/C++ then Java a distant third.

Andrew
(e-mail address removed)

 

[Michele Simionato]

Lest anyone infer that Lisp has an "application niche" consisting of
AI and theory of programming languages ... take a look at

http://www.franz.com/success/

and glance at the column on the left.

Okay, let's restate my point in this way: if you need a very big
programming power (which, I agree, is not only needed in A.I. & similia),
then Lisp is a good choice. Most of the people in the word don't need
a very big programming power, though. They can need a very big numerical
power, then they use Fortran. Or they can need moderate programming power
and moderate numerical power (such as in bioinformatics) and then they use
Perl or Python.

I suspect that Aahz' working definition of "successful" had more to do
with success in terms of popularity, rather than success in terms of
technical excellence: please remember that quality and popularity are
very weakly correlated.

If you want to analyze the popularity of a technology, you will get
far better insight by studying the sociological and historical
contexts surrounding it rather then its actual technical merits.

I completely agree.

For example, how many readers of this post will be surprised to learn
that (most) Common Lisp implementations compile to efficient native
machine code, that Common Lisp has an ANSI standard which includes
very powerful support for object-oriented programming (to name but two
features that everybody "knows" it doesn't have) ?

Go on, raise your hand if you thought that "Lisp" is a slow,
interperted functional langugage.

Never thought so. IMHO people don't use List because they don't need it,
not because they think it is a slow, interperted functional language.
There are simpler alternative languages that are good enough for most
people and more suitable in terms of libraries (i.e. Fortran for
numerics, Perl for bioinformatics). Still, Lisp is successful for a
certain audience (I concede, not restricted to A. I. only, but rather
small anyway). So, it is successful but not popular. This was my
point, in contrast to Aahz's view, and I think we agree.


Michele Simionato

 

[Jacek Generowicz]

Never thought so.

Michele,

My post was not aimed at you specifically. It was aimed a lurkers who
might infer that Lisp is only used in AI (or whatever), or who might
have some unfounded assumptions about Lisp which would be re-inforced
by your post.

I was quite sure that my post would not be telling _you_ much you
didn't already know.