Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!cica!iuvax!copper!templon
From: templon@copper.ucs.indiana.edu (jeffrey templon)
Newsgroups: comp.lang.misc
Subject: Re: Fortran vs. C for numerical work
Message-ID: <77124@iuvax.cs.indiana.edu>
Date: 8 Dec 90 05:03:50 GMT
References: <2392:Nov2902:59:0590@kramden.acf.nyu.edu> <7339@lanl.gov> <1990Nov30.145649.17688@ux1.cso.uiuc.edu> <1990Nov30.163613.9562@alchemy.chem.utoronto.ca> <1980@mts.ucs.UAlberta.CA> <18016@hydra.gatech.EDU> <16671@csli.Stanford.EDU>
Sender: news@iuvax.cs.indiana.edu
Organization: Indiana University, Bloomington IN.
Lines: 59

In article <16671@csli.Stanford.EDU> poser@csli.stanford.edu (Bill Poser) writes:
>Would someone care to enlighten me as to why he or she thinks that C has
>a difficult syntax and is difficult to learn? I just didn't have this

	Well, I will try.  I like you did not have any trouble with C, no
real trouble anyway, except perhaps with file i/o which is quite different
than fortran (this is on a vax/vms system) - i still don't understand really
how to open a file so i can write to it and open it at some later date (i
gave up after about a day of trying, and have never used C for anything
except stdio-type stuff (reading from terminal or redirected input.) since.

the problem i think most fortran-scientific-types have with C is that it
is 'economic in expression' to misquote k&r.  constructs like

	b = sqrt( a < 0 ? -a : a)

look very strange to a fortran programmer, compared to

	IF ( a .lt. 0.0) THEN
	   b = sqrt(-1.0*a)
	ELSE
	   b = sqrt(a)
	ENDIF

most scientific types use computers in very brute-force ways, we're not
interested in impressing customers with slickness, etc., so what's taught
are brute-force, simple techniques like the fortran language and the
EDT editor (on VMS).  i got GNU Emacs working at our site about two
years ago, and i can count on one hand the number who use it (about 100
or so use EDT though.)  it just looks too fancy, too complicated, and
it's something new, and well if you start learning something new, when
are you going to stop?  this is the mindset.  they just don't want to
know.  they know how fortran works, and don't want to have to learn something
new where unpredictable things will happen.

there are 'legitimate' reasons too, however, why fortran programmers want to
stick with fortran for numerical-intensive programs (at least under vax-vms).
one is the huge amount of well-debugged code already written.  nobody wants to
rewrite and test a routine for computing racah coefficients in C when there
is already one working in fortran.

	another reason (vms-specific) is that vms C uses the CALLS instruction
to jump to a subroutine, as compared to fortran using CALLG.  CALLS needs
to build the argument list dynamically, at run time, for each subroutine
call, while CALLG relies on the compiler having built the arglist and
providing the its address.  so when fortran calls a subroutine, the current
context is saved, the pointer to the argument list structure is pushed on
to the stack, and bang! you are in the subroutine.  for CALLS, each argument
has to be pushed onto the stack, and this takes enough time to be of concern
if you have some program (like a monte-carlo simulation) which does a lot
of subroutine calls.  this is one reason why i chose fortran over C when
i wrote my simulation program, even though coding the data structures and
writing the parser for the geometry loader was much more difficult in
fortran than it would have been in C.  i just needed it to run fast, since
i was anticipating calculations that would take hours on a vax 8650.

fortran can get away with this because it does not have recursive subroutines.

					jeff