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.