Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!udel!nigel.ee.udel.edu!mccalpin From: mccalpin@perelandra.cms.udel.edu (John D. McCalpin) Newsgroups: comp.lang.fortran Subject: Re: Fortran 90 status Message-ID: Date: 26 Apr 91 15:25:53 GMT References: <1991Apr24.202115.16119@dragon.wpd.sgi.com> <1991Apr25.235111.26282@alchemy.chem.utoronto.ca> <1991Apr26.142249.21064@convex.com> Sender: usenet@ee.udel.edu Organization: College of Marine Studies, U. Del. Lines: 22 Nntp-Posting-Host: perelandra.cms.udel.edu In-reply-to: bleikamp@convex.com's message of 26 Apr 91 14:22:49 GMT >> On 26 Apr 91 14:22:49 GMT, bleikamp@convex.com (Richard Bleikamp) said: Richard> The new standard has de-emphasized execution time Richard> performance in order to make the programmer's life easier. Richard> To do this to Fortran, long known for its good execution Richard> speed, seems a little crazy. On the other hand, many of us think that to *not* trade execution time for reliability, reusability, and ease of programming it a little crazy! You can still use the "fast" subset of Fortran Extended when speed is critical. Of course it is a very tough tradeoff. When I am developing applications I curse Fortran extensively because of its archaic structure and lack of error-checking. When I am doing science and need 500 Cray Y/MP hours to get my work done, I curse other languages (which have wonderful features that I would really like to use) for not running as fast as Fortran. -- John D. McCalpin mccalpin@perelandra.cms.udel.edu Assistant Professor mccalpin@brahms.udel.edu College of Marine Studies, U. Del. J.MCCALPIN/OMNET