[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.
The reply "C++ is even worse", while debatable either way, seems to be a common response from Fortran defenders. It misses the point. What the scientific community needs, whether they know it or not, is high-performance Python if that's possible, or something as close to it as possible. Specifically, something with serious introspective power and economy of expression. > > I prefer my languages to be portable, terse and expressive. > > Fortran programmers are generally happy with the portability of the > language. Until they try to port something...? Honestly, I can't imagine where anyone would get this impression. Now, about the terseness and expressiveness? > For scientific computation, consider the case of Numeric > and Numarray. I'm not happy with these, because they either make temporary arrays with wild abandon, or enforce an unnatural style of expression. I could see how they would be useful to others but they are awkward in long-time spatially coarse finite difference/finite volume/spectral calculations, which is the problem space I care about. As for non-coarse (finite element) integrations (where rectangular decompositions do not suffice) it seems to me that using Fortran is sheer madness, even though there are real pointers now. I do not suggest that Python is currently competitive with C++ or Fortran. I simply agree with http://www.fortranstatement.com that something new ought to be designed, that a backward compatible Fortran2003 cannot possibly be it, and that attention to fortran diverts resources from teh osrt of genuine progress that ought to be possible. > 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 > has been mentioned, one could use a faster compiler to compile CPython > on Linux, but AFAIK this has not yet been done. Without disagreeing with Alex Martelli's response to this, I find it nonsensical on other grounds. Performance portability has nothing to do with what I'm talking about. The answer belies the attitude that programmers are there to put in time and expend effort, because the only resource worth considering is production cycles on a big machine. This attitude explains why working with Fortran is so unpleasant an experience for anyone who has been exposed to other languages. An alternative attitude is that the amount of human effort put into solving a problem is a relevant factor. In this view, "portability" is actually about build effort, not runtime performance. Perhaps the Fortran community finds this idea surprising? Getting a python package working usually amounts to an install command to the OS and an import command to the interpreter. Then you can get down to work. Getting a Fortran package working involves not only an endless dance with obscure compiler flags and library links, but then a set of workarounds for codes that produce expected results on one compiler and compile failures or even different results on another. The day when project cost was dominated by machine time as opposed to programmer time is coming to a close. Fortran is a meaningful solution only to the extent that programmer time is not just secondary but actually negligible as a cost. The assumption that portability is somehow about performance belies total lack of concern for the programmer as a resource, and therefore to the time-to-solution of any new class of scientific problem. The result of this habit of thought (entirely appropriate to 1955) is that in an environment where fortran is expected, new problems are interpreted as changes to old problems, and the packages become vast and bloated. Since most of these legacy codes in practice predate any concept of design-for-test, they are also almost certainly wrong, in the sense that they are unlikely to implement the mathematics they purport to implement. Usually they are "close enough" for some purposes, but it's impossible to delimit what purposes are inside or outside the range of application. > Nobody is stopping Python developers from working on projects like > Psyco. They aren't helping either, for the most part. Psyco aside, institutions that ought to be supporting development of high-performance high-expressiveness scientific languages are not doing so. Institutions with a Fortran legacy base are confused between maintaining the existing investment and expanding it. The former is frequently a mistake already, but the latter is a mistake almost always. This mistake drives investment of effort in inefficient directions, where efficiency is about design and build cost-to-solution rather than runtime cost-of-execution. > So uninterested in interoperability is the Fortran standards committee > that they added interoperability with C in Fortran 2003 standard. Er, replaced the modest C interoperability they lost in F90, right? The codes I care about aren't new ones. So now I have to hack into the code and redeclare all my arrays, right? So that they'll have a defined structure? And hope that doesn't break some other assumptions? Except that I have to await someone actually releasing an F03 compiler, right? Thanks. It turns out that I need a compiler, not a specification, unfortunately. Even so, I understood that there was some resistance to even this level of interoperability, because it breaks the Fortran no-convention convention. C-interop vapor-mode will require, (oh horror!) a specification for which bytes represent what. Now each vendor will have to try to patch that back in to their idiosyncratic representation. They'll probably get it mostly right, eventually. > > Python fundamentally respects the programmer. > > What does that mean? > If you don't know by now, don't mess with it. mt -- http://mail.python.org/mailman/listinfo/python-list
