nelson@avsdS.UUCP (06/18/84)
# I was once and will soon again be a geophysicist. At the US Geo. Survey in Menlo Park we were using C for new software. Many universities are also using C in their geofizzies deptartments. Over 3 years ago the Survey ported the IMSL library to UNIX f77. It is a pain, but not hard to call f77 programs from C and vis-a-versa. UNIX f77 is slow, but C is not - let's face it, someday the scientific community will have to grow out of FORTRASH. Aside from complex variable types, FORTRASH has nothing going for it. On the matter of fixed array sizes: all compiled languages that I currently know of require a constant array size declaration (the linker needs to know). However, the subroutines only need dummy arguements [note: not true of Pascal, and a real tragedy for scientists!]. You do not need to know about pointers to write scientific procedures in C! You do need to know the size of all but the last dimension in multi-dimensional arrays. C FORTRAN ________________________________________________ float x[]; real x(1) float x[][N]; real x(n,1) float x[][M][N]; real x(n,m,1) Note that the dimension sequence is reversed (x,y,z vs. z,y,x). The parameters m and n can be passed as args in FORTRAN, but in C must be compile-time constants. If you can include the source code with your program, this is no hardship. If not, the routine is presumably in a library, and someone has presumably spent time to ensure that it runs properly before committing it to general use. At that stage the array references as above can be recoded into pointer references. This is not the best state of affairs, but is a very reasonable alternative to staying with FORTRAN. Having coded for 13 years in FORTRAN and 4 in C, I can say that much better code can be written in C - the control structures are "light years" ahead of F. Most of my programs are also designed to be used by others, meaning they have to be somewhat "user-friendly", meaning I need decent string support. Also, in seismology we are working more and more with databases. Things like this are just disgusting to do in FORTRASH. For UNIX users that insist on FORTRAN there is not only RATFOR, but also ECL - a superset of RATFOR that is much more C like. The ECL preprocessor also produces F code with sensible line numbers, indentation, and sensible variable names. Ever try to comprehend the output of RATFOR? Frankly, the idea of preprocessors is horrible - one more step, too much time, and then try debugging the program! An aside on multi-dimensional arrays: I now write all my C programs such that multi-dimensional arrays are data structures that contain array as well as the sizes of its dimensions and other pertinent information about the data. Thus in C I can call a procedure like "massage_data(dataset)", instead of "massage(data, n1, n2, n3, ...) in FORTRAN. Glenn Nelson Ampex Corp., Redwood City, CA ...!{nsc|hpda|megatest|amd70}!fortune!dsd!avsdS!nelson 415-367-2499 "See earth-shaking events in your own home!"
alexc@dartvax.UUCP (Alex Colvin) (06/26/84)
There's been a lot of loose talk here about the demerits of Fortran and the merits of C. Thosae who've already grown tired of this subject are encouraged to type whatever it is that gets them to the next article. As far as I can see, the original point here is that UN*X has a terrible implementation of Fortran. I don't think anyone refuted this. All they came up with was the counter that C is what you should be using on UN*X. I'd have to agree. UN*X doesn't seem to support any other language as well. Those who need Fortran, who have large Fortran applications, probably shouldn't be using UN*X. The C proponents have pointed out a number of failings in Fortran. The control structures of C are a little more sophisticated than those of Fortran. I don't know whether F77 allows you to pass functions around, implementing yr own control structures. It doesn't usually allow or encourage recursion. Etc. etc. On the other hand, the C fans I know seem pretty blind to their favorite lingo's failings. C, for example, doesn't really implement arrays. Just pointer arithmetic. I admit that the latter is useful, but think about trying to add array bounds checking to a C program. It's not unusual to have this feature available for Fortran. Then there is the C expression syntax. 15 levels of operator precedence. Some associate left, others right. 9 kinds of prefix operator. 33 infix. Two enfix, and the ?:. In APL at least, with its half a hundred operators, they decided that no one could be expected to remember the precedence, so there's a simple rule (broken only for functionals!). Consider also (4)*3. Now (int)*ptr. How about (A)*B? ... Just tired of C A. Colvin