dgary@ecsvax.UUCP (06/18/84)
<> >From: anand@utastro.UUCP Mon Jun 11 08:05:01 1984 > >My recommendation is DON'T GET UNIX!!!!!!!!!!!!!!! > >A lot of scientists still use FORTRAN, so a shaky, unreliable >f77 compiler is a severe drawback, and I believe a scientific, heavily >arithmetically oriented department cannot afford to base its computation >on UNIX's FORTRAN. >From: elt@astrovax.UUCP Tue Jun 12 10:47:25 1984 >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. > >Of course, switching to C cannot be the whole solution given the existence >of enormous amounts of useful FORTRAN code, portability requirements, and >the fact that some people simply won't switch. There must be a substantial >amount of money to be made by producing a first class FORTRAN compiler that >runs under 4.2. Having spent a good portion of the last decade giving hell to physicists for using FORTRAN, I'm a little sheepish about coming to its defense. It is certainly true that FORTRAN is an awful language from many standpoints. It is also true that a good part of the reluctance to switch from FORTRAN to something better is plain old inertia. But I have reservations about C being better than FORTRAN for scientific programming. In fact, I don't know of anything better than FORTRAN for scientific programming (he said, crawling into his well-protected bunker). FORTRAN is unique among modern programming languages of any wide use and acceptance in that it is specifically designed for numeric programming. It has an exponentiation operator (**). It has a large, STANDARD set of function names for widely-used functions. (I consider this its single greatest strength, by the way.) It has an immense body of non-standard but widely available, pre-coded scientific functions (IMSL, for instance). The only competition I see on the horizon is (heaven help us) Ada. If you are aware of a language (other than Ada or PL/I) that does numerical programming as well as FORTRAN, please, PLEASE tell me. In the meantime, a good preprocessor for FORTRAN 77 may be the best thing for scientific programmers to use. Defensively, D Gary Grady Duke University Computation Center, Durham, NC 27706 (919) 684-4146 USENET: {decvax,ihnp4,akgua,etc.}!mcnc!ecsvax!dgary
allan@noao.UUCP (06/19/84)
I would like to agree that fortran is a good language for number crunching
type programs. Of course, for other types of programs it leaves a lot to be
desired, but most/many/some/my scientific programs are just number crunchers.
If you have a good optimizing compiler then they are hard to beat.
One example with which I am particularly familiar:
Dr. Richard James at Manchester has a large N body program to simulate
spiral galaxies. It is very important to make this program run as quickly
as possible since each run of the program takes several hours on a CDC7600
(this story is from the pre-Cray days). To try to speed up critical sections
of the code he tried writing some routines in assembly language. He often
found that he could not improve on the code that the compiler generated.
I think that, inetia apart, there are some good reasons for keeping fortran
around. These days the fastest computers have what might be loosely termed
'array processor' architectures, e.g. hardware vector operations (Cray & CDC205)
and array processor add-ons for vaxes. To make the best use of the speed of
these computers it is necessary to use a language that can easily take advantage
of the hardware features. An advantage of fortran for this task is that it is
a fairly simple language. I believe that it is the only language that has
had optimization features included for the array processor architectures
(of course, this is because it is the language that scientists use .... ).
Languages such as C and Algol68 are very nice to use for non numerical
applications where the (still) primitive character features of fortran are
a real pain, but when you must have the greatest speed possible in a numerical
application, you simply cannot beat fortran.
Peter Allan
Kitt Peak National Observatory
Tucson, Az
UUCP: {akgua,allegra,arizona,decvax,hao,ihnp4,lbl-csam,seismo}!noao!allan
ARPA: noao!allan@lbl-csam.arpagraham@convex.UUCP (06/20/84)
#R:ecsvax:-273500:convex:37000003:000:422
convex!graham Jun 20 13:44:00 1984
> FORTRAN is unique among modern programming languages of any wide
MODERN?? Around here, we call it COCKROACH, recalling a comment made by
Mark Halpern:
FORTRAN is the cockroach of the software world:
Its been here forever
It will never change (f77 retains most of the quirks of f66)
It will be here forever
or words to that effect.
Marv Graham; ConVex Computer Corp. {allegra,ihnp4,uiucdcs,ctvax}!convex!grahamgoldberg@uiucdcs.UUCP (06/22/84)
#R:ecsvax:-273500:uiucdcs:26400016:000:655
uiucdcs!goldberg Jun 21 21:18:00 1984
I have no complaint with FORTRAN's number-crunching abilities, but when it
comes to I/O the language is a big loss. Just recently, on our RT-11 V5.1
system, we replaced one output subroutine in a graphics library which did its
I/O with a FORTRAN WRITE with the equivalent subroutine using RT-11 Syslib I/O.
This resulted in a speedup of something like 600%. The net result was that the
Prof. in charge bitched us out for not having done it 2 years ago, since it
only took 5 minutes to make the change.
Phil Goldberg
U of Illinois @ Urbana-Champaign
...!{ihnp4,convex,pur-ee}!uiucdcs!goldberg
goldberg.uiuc@csnet.arpadarryl@ism780.UUCP (06/23/84)
#R:ecsvax:-273500:ism780:14700003:000:238 ism780!darryl Jun 18 19:20:00 1984 APL: Exponentiation. Large body of built in functions. Great for handling multidimensional matricies. A good implementation does not have to take much overhead for interpretation. --Darryl Richman ...!cca!ima!ism780!darryl
rcd@opus.UUCP (Dick Dunn) (06/26/84)
I think thatthe following is a very poor argument in support of FORTRAN: >I think that, inetia apart, there are some good reasons for keeping fortran >around. These days the fastest computers have what might be loosely termed >'array processor' architectures, e.g. hardware vector operations (Cray & CDC205) >and array processor add-ons for vaxes. To make the best use of the speed of >these computers it is necessary to use a language that can easily take advantage >of the hardware features. An advantage of fortran for this task is that it is >a fairly simple language. I believe that it is the only language that has >had optimization features included for the array processor architectures... The first problem here is the confusion between "language" and "implementation". In fact, FORTRAN (the language) has NO support to speak of for vector operations. The "simplicity" of FORTRAN is a curse, not a blessing. It is only by considerable work inside FORTRAN compilers that they are able to generate any vector instructions at all. I rather pity the scientists and compiler writers: The scientist must absolutely rape his algorithms to turn all of the vector operations into explicit loops; then the compiler writer has to bend over backwards to rediscover the vector operations that were obscured in the coding. The real reason that FORTRAN hangs on in the scientific community is pure inertia. There is so much code written that most scientists can't afford NOT to use it. The huge body of existing code makes it economically worthwhile to create the "vectorizing" compilers, onerous tasks that they are. The primitive nature of FORTRAN doesn't make it more desirable to try other languages. Instead, it increases the inertia, because the programs are physically larger, less clear, and harder to maintain or modify. [Compatibility is an albatross.] -- Dick Dunn {hao,ucbvax,allegra}!nbires!rcd (303)444-5710 x3086 ...Cerebus for dictator!
gurr@west44.UUCP (Dave Gurr) (06/26/84)
< force of habit .. > > In the meantime, a good preprocessor for FORTRAN 77 may be the > best thing for scientific programmers to use. Try 'ratfor' (no, dummy, it means RATional FORtran, not fortran for rats!). Most of you will have heard of Kernighan and Plauger's book 'Software Tools', in which RATFOR is described and used. We have a PR1ME 750 here at Westfield which is running Georgia Tech's wonderful (but soon to disappear - sob!) Software Tools sub-system. This is written entirely in RATFOR. RATFOR works. It looks like C. It generates FORTRAN. What more do you want? mcvax "You can't clean the \ toilet Neil, real students ukc!west44!gurr don't do that!" / vax135 Dave Gurr, Westfield College, Univ. of London, England.