chris@spock (Chris Ott) (03/30/88)
lamaster@ames.arpa (Hugh LaMaster) writes: > 3) Fortran is not a bad programming language, even for systems programming. Baloney. I've done systems programming in Fortran before, with the best compiler I've ever worked with. It stinks. C is FAR better for systems programming. > Now C bigots will note that C has modules and internal procedures, and, yes, > it does have advantages as a system implementation languages. But, for a > Fortran replacement it is hopeless. The syntax is confusing and more error > prone than Fortran, but even worse, because C doesn't have dynamic array > dimensioning you can't use it for separately compiled libraries like > Linpack. When was the last time you programmed in C? If I remember correctly, C does have dynamic array dimensioning. I can't say for sure because I don't often use arrays with more than one subscript. Not only that, but C, with its alloc() and free() routine can dynamically allocate memory while the program is running, something I've never seen Fortran do. > Fortran is intrinsically neither more nor less portable than C. Not intrinsically, but in practice, C is a lot more portable than Fortran. I've had no trouble transporting C programs between UNIX machines and very little trouble transporting them between non-UNIX machines. I have never been able to transport a Fortran program without doing a lot of work. > Thousands > of Fortran programmers have run Linpack programs on their machines with > no modifications. And thousands of C programmers continue to write code > which depends on the existence of data types of certain sizes ( e.g. 16 bit > ints), on machine dependencies such as byte order, and indeed on how the > compiler will allocate the fields in a structure (just like the infamous > Fortran equivalence!)... Come on, this is true of ANY language, including both C and Fortran. Good programmers know how to account for these differences. Look at GNU Emacs, for example. This program runs on many different machines and all that needs to be changed is a few lines. It's so easy, even a beginner can do it. I know, because I did it when I was a beginner. C even helps you out with the sizeof() function, which Fortran doesn't have. Now, don't get me wrong: I'm not completely knocking Fortran. It's just that there are a lot of things that C does better. Sure, if you're doing computation, Fortran is better. It has intrinsic math functions that can be easily converted into in-line code, rather than using function calls, like C. It also has the exponentiation function (**) that C doesn't have. It has the complex variables that C doesn't have. Finally, yes, Fortran is just as portable as C when you are ONLY doing computation. Once you get out of the computational domain, however, Fortran just doesn't cut it. I used to do a lot of work with character strings in Fortran. Most compilers I've worked with don't even handle the substring operations defined by the Fortran 77 standard. Let's face it: strings were an after thought in Fortran and they are inadequate, at best. I/O isn't standard, either. I have never seen two compilers whose options lists for OPEN, READ, WRITE, and CLOSE were the same. Even the I/O itself isn't done the same: Sun Fortran is the only one I know that writes the record length at the beginning and the end of an unformatted record. In C, this is all under user control. Well, that's my two cents. Any comments or flames? Oh, I almost forgot. Please redirect any responses to this article to comp.lang.fortran. The comp.arch people are beginning to get upset, for good reason. ------------------------------------------------------------------------------- Chris Ott Computer-Aided Engr. Lab The right half of the brain controls the University of Arizona left half of the body. This means that only left handed people are in their right mind. Internet: chris@spock.ame.arizona.edu UUCP: {allegra,cmcl2,hao!noao}!arizona!amethyst!spock!chris -------------------------------------------------------------------------------