Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 (Tek) 9/26/83; site teklabs.UUCP
Path: utzoo!watmath!clyde!burl!mgnetp!ihnp4!houxm!houxz!vax135!floyd!harpo!decvax!ucbvax!ucbcad!tektronix!tekchips!teklabs!carlc
From: carlc@teklabs.UUCP
Newsgroups: net.physics
Subject: RE: UNIX for physicists
Message-ID: <2876@teklabs.UUCP>
Date: Wed, 13-Jun-84 14:18:37 EDT
Article-I.D.: teklabs.2876
Posted: Wed Jun 13 14:18:37 1984
Date-Received: Fri, 15-Jun-84 01:36:46 EDT
References: <90@utastro.UUCP>, <374@astrovax.UUCP>
Organization: Tektronix, Beaverton OR
Lines: 46

> The best solution, in my opinion, is to switch to C thus getting a good
> compiler and a superior language; to the extent that the new f77 compiler
> motivates people to do this, it may be a good thing.  Incidentally, the
> advantage to a physical scientist of a computer language superior to
> FORTRAN is analogus to the advantages of a superior mathematical notation.

I agree that C is superior in many respects to Fortran.  As to it being
a "superior notation" for scientific programming -- well, maybe.  Certainly,
pointers are nice and its good to have other data structures besides
the array.  But Fortran has some things going for it.  (First, a caveat:
I am not much of a C programmer.  There may be useful things in C of which
I'm unaware.  Please inform rather than insult me if I'm wrong.)

1) complex data type.  This is very handy in many physical problems,
especially when dealing with wave phenomena, Fourier transforms, and such.
Especially in speed-critical applications, I have found that the CEXP
funcion is useful for getting both the sine and cosine of the same
argument without making two function calls.

2) A large number of available subroutine packages for scientific
applications, e.g. the IMSL library.  I have never engaged in a major
programming effort which didn't make use of one or another subroutine package.
There are probably ways to link C code to these packages, but I expect
that portability suffers as a result.

3) Variable dimension arrays.  It appears to me that C requires constant
dimensions in array declarations.  This limits flexibility in
utilizing storage space, especially in simulators for solving differential
equations.  Fortran has an extensive set of rules (not all of which make
sense to me) about how subroutines may structure their dummy arrays.
C just seems to say "here's a pointer to the beginning of the array,
do the rest yourself."  If you want variable dimensions, or variable
numbers of dimensions, you must do subscript calculations yourself.

The main point is that Fortran was written for scientific programming.
C was written for fun.   UNIX(tm) in general emphasizes text-processing
applications over number-crunching applications.  (But who'd want
to number-crunch on an overloaded VAX, anyway? -) ) Rather than hop on
the C/UNIX bandwagon, why doesn't some erstwhile group of scientists
and programmers go to work on creating a modern language for scientific
applications?  Fortran-88?  If Fortran could be weaned from its historic
dependence on punched cards and its fear of blanks, and given a wider
variety of data strucures, it could remain an extremely valuable tool
for scientists.  Perhaps a Ratfor-type preprocessing scheme could
achieve some of these ends while maintaining compatibility with
Fortran-77.