Path: utzoo!attcan!uunet!gistdev!flint
From: flint@gistdev.gist.com (Flint Pellett)
Newsgroups: comp.lang.misc
Subject: Re: C vs. FORTRAN (was C official DOD langauge?)
Message-ID: <915@gistdev.gist.com>
Date: 7 Jun 90 15:40:12 GMT
References: <1633@dinl.mmc.UUCP>
Organization: Global Information Systems Technology Inc., Savoy, IL
Lines: 58


I've always strongly believed that the choice of what language to use
for a particular purpose depends upon the purpose you have in mind.
Therefore, it is impossible for us to reasonably recommend whether
your friend should switch from Fortran to C without knowing what he
is trying to do.  (Or whether he should forget both of them and use
something else.)  Here are some tidbits that may help:

1. It is rumored that AT&T will not support a FORTRAN compiler in their
System V Release 4: the reason being that, with the change over from
the COFF to ELF object formats they didn't feel it was worth the work
to build/fix their Fortran.  I don't know if this rumor is true, and
even if it is I'm sure you'll be able to get 3rd party compilers.
However, it is easy to get C, getting a Fortran that will compile
your code correctly isn't always so easy.  (I think it is rather like
getting parts for a special foreign car-- you can generally do it, but
it takes a lot of effort to locate them sometimes.)  From my own
experience, I once had to try compilers from 4 different vendors
before I found one that didn't have a fatal limitation for my
application.  Two examples I remember: Micro-Soft's (brain-damaged)
compiler only allowed values in the range from -32,767 to 32,767 in
a signed INTEGER*2 (2 byte) variable: note the absence of -32,768.
Because they decided to make the bitpattern 0x8000 a special case
and not allow you to use it, all my code to build up 16-bit bitmaps
could not be guaranteed to work unless I was willing to store all
my 16 bit bitmaps into 32 bit variables.  Another compiler I tried
out decided that character arrays never have to be longer than
255 characters.  (No, they couldn't even be nice enough to allow
256, not that it mattered- when you want to process file names with
1024 characters in the path, such a limit is death.)

2. Fortran has more developed math libraries, but the rest of the
libraries available for it are far more limited.  You're not likely
to find standard library routines for updating /etc/passwd in any
Fortran libraries: even stuff as basic as getopt() doesn't seem to
have a standard in Fortran.  The math stuff isn't portable either:
if you like having to run scripts to change all your xor() calls
into ieor() for the new machine get Fortran.

3. Optimization in C vs. Fortran has a lot less effect than other
factors, such as the algorithm and how well it is written.  One
example: by recoding a binary search routine that was originally
written in Fortran (and reasonably well) into C to call the bsearch()
library routine, I made significant speed improvements in a program.
When done, I had 1 line of code to maintain instead of many.
I would never choose a language based on how well it can be
optimized-- choose the language based upon how well it allows you
to express the algorithm you're trying to write.

In case you haven't guessed by now: in 95 applications out of 100
I'd recommend using C over Fortran.  About the only time I ever
went with Fortran was for doing solutions of complex differential
equations and related numerical analysis work, because the packages
to do it were available.
-- 
Flint Pellett, Global Information Systems Technology, Inc.
1800 Woodfield Drive, Savoy, IL  61874     (217) 352-1165
uunet!gistdev!flint or flint@gistdev.gist.com