Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!mordor!sri-spam!ames!ncar!oddjob!gargoyle!att-ih!ihnp4!inuxc!iuvax!pur-ee!uiucdcs!uxc.cso.uiuc.edu!uxe.cso.uiuc.edu!kelly From: kelly@uxe.cso.uiuc.edu Newsgroups: comp.arch Subject: Re: FORTRAN Horror Message-ID: <46500011@uxe.cso.uiuc.edu> Date: 27 Mar 88 22:06:00 GMT References: <1135@pembina.UUCP> Lines: 62 Nf-ID: #R:pembina.UUCP:1135:uxe.cso.uiuc.edu:46500011:000:3804 Nf-From: uxe.cso.uiuc.edu!kelly Mar 27 16:06:00 1988 /* Written 9:15 pm Mar 24, 1988 by jlg@a.UUCP in uxe.cso.uiuc.edu:comp.arch */ In article <17739@watmath.waterloo.edu>, rwwetmore@watmath.waterloo.edu (Ross Wetmore) writes: > I think this is an area where the classic symptoms of moral superiority > abound. Computer science has progressed beyond the capabilities of Fortran > and now views it with disdain as neanderthal. Scientists whose interest is > not in computers themselves, but in the results they produce, are quite > content to employ known and trusted tools if they do the job, and find it > extremely frustrating when these tools are taken away and if at all replaced, > then replaced with buggy new tools that are totally untrustworthy. Bravo! Not only that, the languages that computer scientists claim are so much more advanced often are not nearly as good as Fortran for the task of ordinary number-crunching. There is no a-priori reason that a language that was designed for compiler or operating system implementation should do scientific code as well as Fortran does. And, in fact, none do. J. Giles Los Alamos /* End of text from uxe.cso.uiuc.edu:comp.arch */ I see a lot of people claiming that fortran is a wonderful number-crunching language. In my experience, even if this assertion has basis in fact, it is irrelevant to your average engineering (including myself) or scientist programmer. A well designed compiler will make a difference of about a factor of two in how fast a code runs. This difference between a so called good/bad programming language would not be more than 20%. The fact is your average engineering (including myself) or scientist programmer hasn't a clue how to write good fast code. And it is almost certain that any reasonably large code we write, can be made run at least 2 times faster by changing how it is coded. It is also true that for 99 percent of the code that we write, it doesn't matter how fast it runs, the most important aspect of the code is that it is maintainable. Now we get to our weather forcasting code, which predicts exactly what is going to happen in the next 24 hours but which takes 27 hours to run. When you go to optimize that code, it is much more important that the user can easily see what is going on in the code, than it be in the most efficient numerical programming language. If the person who is optimizing the code can see what calculations have to be carried out, then they have some chance at deciding on the most efficient algorithm for the job. Unfortunately, fortran has a habit of totally diguising the underlying algorithm. The reason scientists and engineers write programs in fortran is because we have been taught computer programming in fortran. This is sad, because learning another computer language really enhances one's programming ability. Good code can be written in any language, but one has to know another programming language in order to write good programs in fortran. My chief beef against fortran is that it is non portable. ANSI fortran is portable; but it is such a limited language, it has to be extended to make it useable for any large scale program. If you don't believe me, look at any large finite element code. All of them rely on extensions to fortran 77, extensions which in most cases are not portable. An addendum to the efficiency business: the author of a large commercial finite element code said to me once, "we rely on good optimizing compilers for performance". In my opinion this finite element code, is one of the most efficient available for the class of problems it solves. The reason it is so efficient is because the author selected the best algorithms available and not because of the efficiency of fortran as a number crunching language or because of the quality of the implementation.