Path: utzoo!attcan!uunet!husc6!mailrus!iuvax!pur-ee!uiucdcs!uxc.cso.uiuc.edu!uxe.cso.uiuc.edu!hirchert From: hirchert@uxe.cso.uiuc.edu Newsgroups: comp.lang.fortran Subject: Re: Should I convert FORTRAN code to C? Message-ID: <50500055@uxe.cso.uiuc.edu> Date: 14 Jun 88 16:19:00 GMT References: <2742@utastro.UUCP> Lines: 121 Nf-ID: #R:utastro.UUCP:2742:uxe.cso.uiuc.edu:50500055:000:8102 Nf-From: uxe.cso.uiuc.edu!hirchert Jun 14 11:19:00 1988 FORTRAN remains the preeminent language for numerical (esp. scientific and engineering) computing for a number of reasons: o Inertia - Much scientific and engineering computing is based on earlier work. If that earlier work is in FORTRAN (and the odds are that it is), then it is usually easier to continue working in FORTRAN than to switch to another language. [This effect may be reduced somewhat if automatic language conversion programs become both more reliable and more widely available. However, unless someone figures out how to translate the comments from describing the source language to describing the result language, there will always be some barrier here to language switching.] - Many of the people doing scientific and engineering computing are professional scientists and engineers and only part-time programmers. Since programming is not their business, they are far more likely to be proficient in only a single language, so even when projects are started from scratch, they are far more likely to use the language that they are already using when building on existing work - FORTRAN. [This effect may be reduced as more and more colleges and universities teach languages other than FORTRAN to their science and engineering students. On the other hand, if one's only exposure to a language is a few class problems, one may still feel uncomfortable using that language for "serious" computing.] o FORTRAN is, in a number of ways, a superior language for many kinds of numeric computing. - Features . FORTRAN includes a number of features that many more "modern" language make you build yourself from more basic features. The classic example is the COMPLEX data type. A less appreciated example is FORTRAN formatted input/output. If you are reading and writing the classic tables of numbers and labeling information, it is a substantially more compact and more convenient tool than what is offered in most more "modern" languages. (Of course, if you want to some other kind of textual input/output, it can be a major pain.) [In theory, the "modern" languages could match this power with library procedures of comparable power. In practice, the portable routines tend to make FORTRAN input/output look fast and the fast routines tend not to be portable. The development of standards, so the fast routines are all written to the same specification, would help here.] . The FORTRAN programmer usually has access to a much wider selection of "canned" numerical software than the programmer in other languages. (This is an outgrowth of the inertia factor.) [Automatic translators can help with this problem when source code is available. Mixed language programming environments can make irrelevant the issue of what language was used to code your "canned" software. Unfortunately, the way two languages interact seems to vary significantly from environment to environment, so mixed language software tends to be less portable than software written in a single language. This is another area where the development of standards might eventually reduce FORTRAN's advantage.] - FORTRAN compilers tend to produce faster code. . Historically, vendors have put more effort into optimizing FORTRAN than other languages. (Inertia again.) [This effect is slowly being reduced by an increased demand for optimizing compilers for other languages and by the increased use of techniques such as common compiler back-ends to facilitate meeting these demands.] . FORTRAN is inherently more optimizable (using today's compiler technology) than most more "modern" languages. FORTRAN is close enough to the machine to avoid the problem of being forced to do extensive analysis/optimization just to produce reasonable code, but far enough removed from the machine to allow the application of such analysis/ optimization to produce signficant improvements. In particular, where other languages frequently insist on complete and orthogonal definitions, FORTRAN will disallow unusual (and unlikely) combinations of features if this will allow significant improvements in the generated code. The classic (and single most important) example of this are the restrictions in FORTRAN concerning the use of the same or overlapping actual arguments corresponding to the dummy arguments of a procedure. These restrictions allow a wide range of optimizations, from removal of loop invariants and recognition of common subexpressions to vectorization, to be applied to dummy arguments in the same way they are applied to ordinary variables. [This inherent advantage may not always be realized. If a vendor uses a common compiler back-end, he may forego these optimizations in order simplify its use. Alternatively, he may provide for compiler directives that allow the programmer in a more "modern" language to explicitly assert the restrictions implicit in FORTRAN. (As I understand it, that's what the ANSI C noalias controversy was all about.)] From my point of view, all of the above suggests that FORTRAN will be around for some time to come. On the other hand, the factors I mention in my bracketed comments will tend to reduce FORTRAN's advantages, FORTRAN is most definitely not without its deficiencies: o FORTRAN's memory management is inadequate for many of todays problems. o The array is not sufficient as the primary data organizing facility. (Structured data types would provide assistance in expressing fixed relations between non-heterogenous data. Pointers, or something with equivalent semantic power, would provide assistance in expressing more dynamic or less uniform relations.) o As typical portability requirements expand from porting programs from unlike systems on a one-shot basis to running programs under continuing development on several systems simultaneously (e.g. doing test runs on a workstation and production runs on a supercomputer), FORTRAN needs to provide more assistance in writing portable code. A classic problem in this area is switching between the use of REAL and DOUBLE PRECISION, including the related problems of switching constants and name management for libraries offering both REAL and DOUBLE PRECISION versions of routines. o As the exploitation of parallelism becomes increasingly important in high-end computing, more powerful notation for expressing this parallelism becomes highly desirable. In the long run, the extent to which FORTRAN continues to be used may depend on what is produced as a result of the Fortran 8x effort. If that result retains FORTRAN's current strengths and remedies its most pressing deficiencies, then it seems likely that Fortran will remain the preeminent numerical computing language. If the Fortran 8x process fails to produce a new standard or produces one which is so tied to existing practice that it fails to address FORTRAN's more pressing deficiencies, then a slow (but accelerating) decline seems likely. My guess as the most probable successor would be C. It has some serious problems as a numerical computation language, but the ANSI C committee seems willing to address the extensions and changes necessary to remedy these problems. (Just so no one misinterprets what I'm saying: When I suggest the possibility of a decline in the use of FORTRAN, I'm not talking about something that will happen in the next year or two or even in the next 5 to 10 years. The factors cited at the beginning of this posting are too significant. A significant decline, if it occurs, may well take place over a period of time comparable to the time it took us to get where we are now, and FORTRAN is more than 30 years old!) Kurt W. Hirchert hirchert@ncsa.uiuc.edu National Center for Supercomputing Applications