Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!elroy.jpl.nasa.gov!ames!skipper!altair!maine From: maine@altair.dfrf.nasa.gov (Richard Maine) Newsgroups: comp.lang.fortran Subject: Re: Fortran 90 status Message-ID: Date: 10 May 91 15:22:03 GMT References: <123207.25873@timbuk.cray.com> <1991Apr26.210247.17264@ariel.unm.edu> <3246@travis.csd.harris.com> <1991May10.002337.22669@ariel.unm.edu> Sender: news@skipper.dfrf.nasa.gov Distribution: comp Organization: NASA Dryden, Edwards, Cal. Lines: 62 In-reply-to: prentice@triton.unm.edu's message of 10 May 91 00:23:37 GMT On 10 May 91 00:23:37 GMT, prentice@triton.unm.edu (John Prentice) said: John> that at least so far as my appeal went, I am not asking for all John> the things listed above. Quite the contrary. I am willing to John> live with much inconvience and lack of portability if that is John> the price I pay for really superior performance. John> ... I need a good six orders of magnitude increase in speed John> ... But to exploit that speed, I need languages that address John> parallelism. They don't have to be cheap however. They don't John> have to be portable. They don't have to be easy to use (in some John> sense). And they most certainly don't have to be safe. John> if we keep going the way we are, Fortran is going to become so John> obsolete that it is no longer viable. 15 to 20 years between John> modernizations of the language is too long. I still advocate John> either frequent updates to the standard which incorporate John> existing practice or alternately just giving up on the whole John> concept of standards. I certainly agree that 15 to 20 years is too long and that, in particular, F90 should have been out about 5 years ago. However, I think John asks too much of a standard. One of the primary reasons for having a standard is portability - both in terms of code portability and programmer relearning time. A standard that is not portable is almost a contradiction, and a standard that changes too often also defeats too much of its purpose (at 14 years from 1978 to 1992(estimated), I agree that we are nowhere near the boundary of too often). This does not mean that there is no role for languages or language features that are non-portable and take intimate advantage of the newest hardware. John argues persuasively that he needs such a language and I see no reason to disagree. I just think that what he is talking about is not and can not reasonably be the role of the Fortran standard. It is more in the role of those experimental languages that might provide some of the "existing practice" on which to base the following standard. That "existing practice" does have to come from somewhere. Yes, to get top performance from the newest hardware, you may give up many of the benefits of using an established standard. You may have to put up with non-portable code, lots of time spent in learning proficiency in a new specialized language or feature, expensive software (because of low volume), and other problems. Some of these problems can be ameliorated; others are just part of the cost of doing what you have to do. This being said, there is still a role for standard Fortran (or other standardized languages). The kinds of requirements John describes, although legitimate, are not universal. There are still plenty of applications, where portability, maintainability, and others of the characteristics that John is willing to give up are paramount. In some of these kinds of applications, the role of the standard is crucial, to the extent that you are forced to stick with the standard even when there are demonstrably superior ways of doing the job on a specific system. I guess my posting amounts to mostly yet another "use whatever tool seems best for your application" message. -- -- Richard Maine maine@altair.dfrf.nasa.gov