Path: utzoo!mnetor!uunet!husc6!bloom-beacon!tut.cis.ohio-state.edu!mailrus!ames!amelia!orville.nas.nasa.gov!fouts From: fouts@orville.nas.nasa.gov (Marty Fouts) Newsgroups: comp.arch Subject: Re: FORTRAN Horror Message-ID: <405@amelia.nas.nasa.gov> Date: 28 Mar 88 18:12:05 GMT References: <24861@yale-celray.yale.UUCP> <1135@pembina.UUCP> <2596@pdn.UUCP> <6321@ames.arpa> <17739@watmath.waterloo.edu> Sender: news@amelia.nas.nasa.gov Reply-To: fouts@orville.nas.nasa.gov (Marty Fouts) Lines: 89 In article <17739@watmath.waterloo.edu> rwwetmore@watmath.waterloo.edu (Ross Wetmore) writes: > Consider the following: >1) Scientists are paid to do science in their field, not computer science. > Funding is based on production of tangible scientific results, not in > upgrading software. If your field is (say) Computational Fluid Dynamics, doesn't that make it a computational science? What I mean by this semifacetious remark is that if the science you are trying to do is a model of a physical phenomena, you are going to do a better job of it if you understand the limits and capabilities of modeling. Scientists have always been involved in making the tools they use. Much of mathematics was developed by scientists looking for ways to quantify their results. Current works in optics are being done by astronomers, trying to develop better telescopes, etc. In any field, the better you understand your tools, the better you can use thme. >2) A scientists reputation is based on producing *correct* results. It is > not possible to rewrite and test a 100,000 line package of code, nor is > it possible to do this, on a timescale consistent with changes in computer > technology. True, but many applications are not 100,000 line packages of code. Those scientists who mainly research new algorithms tend to work with much smaller codes. I have seen flow solvers that are only a few thousand lines of code, and we have people here who have translated programs between Fortran, C and Star-Lisp. >3) Previous results and accumulated experience are used extensively in > development and verification. Throwing this out is generally unthinkable. A mistake that can be made here is confusing experience with baggage. Sometimes you can throw the baggage away. Frequently you should throw it away. The experience of assembly language programming led to the development of high level languages. The baggage of assembly language programming (mostly) got thrown away. The same can be true of specific high level languages. >4) Most significant packages in computational science have man-years of > labour built into them, and are not simply screen-sized programs typical > of many in computer science. The problem with quantifiers like "most" are that there probably isn't any good research behind them. Some applications are short. Some are long and have a lot of support. The short ones are usually easy to translate into a new language. The long ones sometimes have large support organizations which can spend some of those man-years translating them into new languages, rather than supporting them in old languages. I would suppose that there are few long ones without support organizations which are of significant interest to the user community. >5) Unless there is a tangible benefit in performance or capability, rewrites > are not ever desirable. It is not even desirable to waste the scientists > time in learning a new machine environment unless there is some concrete > advantage to be gained. I agree. But where there is a benefit, it should be utilized. Also, rewrites don't have to be done by the scientist, they can be done by slave labor (er, graduate students) or by technical programmers. This requires a degree of cooperation and understanding not often achieved, but it might be very beneficial. >6) Few physicists, chemists or social scientists can appreciate (even if they > wanted to) the benefits which are likely to come from new technology > outside their area of expertise. They must be taught and shown remembering > that what is obvious to the computer scientist is not likely to be so to > the physicist, and there is always the chance that the computer scientist > has missed something. > I agree completely. It also works both ways. Few computer scientists have the time to become expert in other fields. Both sides need to recognize that because the other isn't expert in their area doesn't mean that they can not contribute. I have spent much of my career overcoming the assumption of engineers that I am a second class scientist because I *merely* do computers. > What is really missing in all this is recognition by all parties that >teaching and transporting technology from one discipline to another is both >necessary and worthy of the time and expense. The second lesson is don't take >away the tools of one discipline until you have upgraded them and the users >to the next level. On the other side, time spent in learning new techniques >is should not be considered as time wasted, and perhaps woudn't be if the >learning process was facilitated and the benefits clearly visible. > True, but the benefits are rarely visible in advance. This is the frustration of trying to produce them.