Path: utzoo!utgpu!water!watmath!clyde!att!mtunx!rutgers!cbmvax!snark!eric
From: eric@snark.UUCP (Eric S. Raymond)
Newsgroups: comp.lang.fortran
Subject: Re: Should I convert FORTRAN code to C?
Summary: Probably...
Message-ID: <22ad4e5b!4683@snark.UUCP>
Date: 8 Jun 88 14:25:02 GMT
Organization: Eso
Lines: 70

In article <2742@utastro.uucp>, rlr@utastro.UUCP (Randy Ricklefs) writes:
> 1) Are people actually initiating new projects in FORTRAN, or are they
> 	maintaining and porting old FORTRAN code?

New projects are still being initiated in FORTRAN. Lots of old FORTRAN code
is still being maintained, too -- FORTRAN is still the computer lingua franca
of the engineering and scientific world.

> 2) Does the answer to 1) change if we restrict discussion to PC's & Macs?

I am not aware of a FORTRAN for the Mac. Good FORTRANs do exist for the PC/PS
machines (but beware of Microsoft's, which is said to be slow and buggy!).
Sorry for not giving references, but it's been many years since I hacked
FORTRAN myself.

> 3) Is c a suitable replacement for FORTRAN in terms of mathematical capabil-
> 	ities and portablility?

Pre-ANSI C wasn't, quite -- the promote-everything-to-double lossage in K&R
and lack of complex-number support caused problems. ANSI C solves the first
problem, and C++ the second. A perhaps more serious problem is the lack of a
C-portable equivalent of LINPACK (though the UNIX C math libraries cover a 
fair amount of ground).

> 4) Are there reliable FORTRAN to c translators available under MS-DOS or UNIX
> 	that will allow moving over to c without re-coding the world?

I have seen ads for FORTRAN to K&R-C translators. I expect FORTRAN
to C++ translaters with COMPLEX-to-complex mapping will be along any month
now if they're not already here.

Despite problems pointed out under 3), C has gained a lot of ground at former
FORTRAN strongholds during the last five years; it is much easier to code in
and maintain. The rise of UNIX has of course helped it.

Assuming you decide to convert -- *don't* try converting by hand! Assuming you
can get a translator, be aware that none of them are perfect and expect the odd
bug or two to turn up post-translation.

I guess I can sum up my gut feel about the change best with a pair of lists:

Indications *for* switching to C:
   1. Your FORTRAN code base is relatively small (so you don't need the next
five years to satisfy yourself that the translator code did a correct job!).
   2. Your applications have a long expected lifetime.
   3. The code needs to be extended and modified on a continuing basis.
   4. The application wants to run on UNIX or MS-DOS boxes (for the forseeable
future, the best compiler technology is going to go first into C on these).

Indications *against* switching to C:
   1. Translator-introduced bugs (that might be *very* subtle!) could kill
people.
   2. Your applications use COMPLEX (some translators may not handle this).
   3. Your applications use LINPACK or other math functions not available in
the C/UNIX world.
   4. Your application uses EQUIVALENCE or COMMON in weird untranslatable ways.
   5. Your installation is dominated by FORTRAN-head engineer/scientist types
who would be reduced to a pathetic state of confusion by the change.

You *must* budget time for a post-conversion desk check of the generated C!
Lint the whole thing at absolute minimum. If floating-point computation is
involved, have a numerical analyst scan for hotspots.

I hope your circumstances are such that you can attempt this. I'm speaking
only from theory and comparative knowledge of the two languages; I'd really
like to see a how-we-did posting from a shop that actually took the plunge.
-- 
      Eric S. Raymond                     (the mad mastermind of TMN-Netnews)
      UUCP: {{uunet,rutgers,ihnp4}!cbmvax,rutgers!vu-vlsi,att}!snark!eric
      Post: 22 South Warren Avenue, Malvern, PA 19355   Phone: (215)-296-5718