Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!lll-winken!ncis.tis.llnl.gov!lance.tis.llnl.gov!turner
From: turner@lance.tis.llnl.gov (Michael Turner)
Newsgroups: comp.lang.misc
Subject: Re: Fortran vs. C for numerical work
Message-ID: <1183@ncis.tis.llnl.gov>
Date: 4 Dec 90 16:55:58 GMT
References: <1980@mts.ucs.UAlberta.CA> <18016@hydra.gatech.EDU> <16671@csli.Stanford.EDU> <26256:Dec404:30:1390@kramden.acf.nyu.edu>
Sender: news@ncis.tis.llnl.gov
Organization: University of California, Berkeley
Lines: 32

In article <26256:Dec404:30:1390@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>
>[C] just isn't that hard a language to use, folks. Are you a Fortran
>prorgammer who wants to learn C the easy way? Promise yourself to spend
>five minutes a day putting your Fortran code through f2c and reading the
>results until you understand them. Past that you're home free.
>
>---Dan

I guess what bothers me about this advice is that, if taken, it would
increase the number of people who "know C"--but who really don't use much
more semantics than FORTRAN already offers.  I have had to debug large
modules that were not much more than direct translations from FORTRAN
to C, and have found it very frustrating.  A typical problem is:

	float x[MAX_POINTS], y[MAX_POINTS];

where everything refers to the global arrays x and y, rather than defining

	typedef struct {
		float x, y;
	} point;

and supplying a bunch of operations on "points", independent of a
global data structure.  This is not the best example.  Perhaps a FORTRAN
programmer could come up with a better way to encapsulate the concept of
point in FORTRAN.  I know, however, that I tried to write modular code
in FORTRAN for many years, and never felt satisfied with the level of
abstraction that I reached.

Michael Turner
turner@tis.llnl.gov


Brought to you by Super Global Mega Corp .com