Michael Tobis wrote: > > 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.
>From the fact that Fortran has been used on hundreds of platforms and that many portable libraries like LAPACK exist. Fortran 90+ allows one to write even more portable code using the KIND mechanism and the selected_int_kind and selected_real_kind functions, which let you specify the ranges of basic data types. > Now, about the terseness and expressiveness? Fortran 90/95 is more expressive than Fortran 77 in many ways, as described in (for example) pages 7-8 of the essay "Numerical Recipes: Does This Paradigm Have a Future?", available at http://www.nr.com/CiP97.pdf . Quoting that paper: "This, for us, was the revelation of parallel programming in Fortran 90. The use of parallel and higher-level constructions -- wholly independently of whether they are executed on tomorrow's parallel machines or today's ordinary workstations -- expresses more science per line of code and per programming workday. Based on our own experience, we think that productivity, or achievable complexity of project, is increased a factor of 2 or 3 in going from Fortran 77 to Fortran 90 -- if one makes the investment of mastering Fortran 90's higher level constructs." > > 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 Some early Fortran 90 compilers did this but have improved significantly in this respect. > or enforce an unnatural style of expression. I wonder what this means. <snip> > 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 [the sort] of > genuine progress that ought to be possible. You have not given specifics about what "genuine progress" in a scientific programming language would be. <snip> > 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. Nonsense. Fortran was originally created to make PROGRAMMERS more efficient by letting them code algebraic expressions instead of machine code. > This attitude explains why working with Fortran is so unpleasant an > experience for anyone who has been exposed to other languages. "Anyone"? Since I have been exposed to Python and C++ and still find Fortran 90+ enjoyable, your statement is demonstrably false. Have you ever used a version of Fortran past F77? The free Fortran 95 compiler called g95 http://www.g95.org is available. <snip> > 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. If one writes standard-conforming code it does not. At least with Fortran one has multiple independent implementations of an ISO standardized language, about 10 each on Intel Windows or Linux, and 4 for Mac OS X. Links are at http://dmoz.org/Computers/Programming/Languages/Fortran/Compilers/ . If one Fortran compiler leaks memory when multiplying matrices, one can use another. If Python Numarray does, the only alternative I know of is Numeric, which is no longer supported according to http://www.pfdubois.com/numpy/ . I have found it extremely useful to work with multiple compilers and compiler options. A good compiler such as Lahey/Fujitsu has debugging options that aid programmer productivity by finding bugs, both at compile and run time, at some cost in speed. I gave a few examples in a previous thread. The existence of such compilers refutes your assertion that Fortran programmers think only machine time is important. -- http://mail.python.org/mailman/listinfo/python-list