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