<[EMAIL PROTECTED]> wrote:
> Michael Tobis wrote:
> > (unwisely taking the bait...)
> >
> > If you like your language to look like this
> > http://www.cs.rpi.edu/~szymansk/OOF90/bugs.html
> > then more power to you.
>
> Thanks for pointing out that interesting article on Fortran 90 bugs.
> How long would a comparable C++ list be? Even Python has gotchas, for
> example the difference between deep and shallow copies.
C++ "gotchas" spawn whole books. So, once, did C ones -- Koenig's "C
Traps and Pitfalls" is a wonderful book; to be honest, that was only
partly about the _language_... Koenig's advocacy of half-open loops and
intervals is just as valid in any language, but it was still a point
WELL worth making.
The referenced page, in part, is simply pointing out places where
Fortran might prove surprising to a programmer just because it works
differently from some other language the programmer might be used to.
For example, the very first entry just says that '.and.' does not
short-circuit, so when you need guard behavior you should rather use
nested IF statements. This is no bug, just a reasonable language design
choice; anybody coming from (standard) Pascal would not be surprised;
Ada even has two different forms ('and' doesn't short-circuit, if you
want short-circuit you use 'and then').
In some sense it can be a gotcha for some programmers, but it would be
silly to count it as a "fortran bug"! Or even "wart" for that matter.
So, I would try to classify things in three classes:
a. some things are important techniques which one may choose to
highlight in the context of a given language, yet it would simply
be silly to classify as gotchas, warts, or bugs _of that language_;
b. some aspects of a language's behavior are surprising to people
familiar w/other languages which behave differently, and thus are
worth pointing out as "gotchas" though they're surely not bugs (and
may or may not be warts);
c. lastly, some things are irregularities within the language, or
truly unexpected interactions among language features, or vary
between implementations in ways most programmers won't expect;
these can be described as warts (and maybe even bugs, meaning
things that may well be fixed in the next version of a language).
The advantages of half-open intervals (per Koenig's book), the fact that
copies exist in both shallow and deep senses, or the fact that with
pointers to pointers you need to allocate the parent pointers first (the
last entry in the referenced page) are really about [a] -- of course if
a language doesn't have pointers, or doesn't offer a standardized way to
make copies, you won't notice those aspects in that language (the issue
of half-open loops and intervals is wider...), but really these kinds of
observations apply across broad varieties of languages.
Point (b) will always be with us unless all languages work in exactly
the same way;-). 'and' will either short-circuit or not (or the
language will be more complicated to let you specify), array indices
will start from 0 or from 1 (or the language will be more complicated to
let you specify, etc etc), default values for arguments will be computed
at some specified time -- compile-time, call-time, whatever -- or the
language will be poorer (no default values, or only constant ones) or
more complicated (to let you specify when the default gets computed).
Etc, etc.
Point (c) is really the crux of the matter. Generally, simple languages
such as C or Python will have relatively few (c)-warts; very big and
rich ones such as C++ or Perl will have many; and ones in the middle, as
it appears to me that Fortran 90 is, will have middling amounts. I'm
not saying that lanugage size/complexity is the only determinant --
there are other aspects which contribute, e.g., the need for backwards
compatibility often mandates the presence of legacy features whose
interaction with other features may cause (c) moments, so, a language
which is older, has evolved a lot, and is careful to keep compatibility,
will be more at risk of (c)-level issues. Still, size matters. It's
just like saying that a big program is likely to have more bugs than a
small one... even though many other factors contribute (backwards
compatible evolution from previous versions matters here, too).
> > I prefer my languages to be portable, terse and expressive.
>
> Fortran programmers are generally happy with the portability of the
> language. A difficulty with Python portability and maintainability is
> that some needed functionality is not in the core language but in C
> extensions. For scientific computation, consider the case of Numeric
> and Numarray. I don't think Numeric binaries are available for Python
> 2.4,
<http://www4.ncsu.edu/~jdbrandm/Numeric-23.6.win32-py2.4.exe> ? Just
googled and visited the first hit -- I don't currently use Windows so I
don't know if it's still there, works well, etc.
> The recent "Pystone Benchmark" message says that Python is only 75% as
> fast on Linux as on Windows. Fortran programs do not suffer this
> performance hit and are in this respect more portable. In theory, as
You're saying that using a different and better compiler cannot speed
the execution of your Fortran program by 25% when you move it from one
platform to another...?! This seems totally absurd to me, and yet I see
no other way to interpret this assertion about "Fortran programs not
suffering" -- you're looking at it as a performance _hit_ but of course
it might just as well be construed as a performance _boost_ depending on
the direction you're moving your programs.
I think that upon mature consideration you will want to retract this
assertion, and admit that it IS perfectly possible for the same Fortran
program on the same hardware to have performance that differs by 25% or
more depending on how good the optimizers of different compilers happen
to be for that particular code, and therefore that, whatever point you
thought you were making here, it's in fact totally worthless.
> has been mentioned, one could use a faster compiler to compile CPython
> on Linux, but AFAIK this has not yet been done.
We're cheapskates, so we tend to go for the free compilers -- with the
exception of Windows, where I believe Microsoft donated many copies of
their newest commercial compiler to Python core developers working on
Windows (smart move on MS part, makes their platform look better at no
real cost to them).
But the more compilers are in use, the LARGER the variation of
performance I expect to see for the same code on a given box. There
will surely be cheapskates, or underfunded programmers, in the Fortran
world, too, using free or very cheap compilers -- or is your claim that
anybody using Fortran MUST be so flush with money that they only ever
use the costliest tools, and thus that Fortran should not be considered
unless your project's budget for programming tools is Rubenesque? Do
you think the costliest professional compilers cannot EVER find, on any
given benchmark, some optimization worth a 25% speedup wrt the cheapest
or free compilers...?! I really can't believe you'd claim any of this.
Maybe you will want to clarify what, if anything, you mean here.
Alex
--
http://mail.python.org/mailman/listinfo/python-list
