 |
 |
Hi, Van's response to the "RETIRE FORTRAN" also contains a number of distortions and exaggerations, though in a direction opposite of that of the original authors. Here are a few. On Fri, 20 Feb 2004, 8:12am -0600, [log in to unmask] wrote: > Sender: [log in to unmask] > Item 1 is wrong: The Fortran 95 standard is 386 pages, not 700 pages. > The C99 standard is 556 pages. > If you're talking about textbooks, consider that the most > frequently-recommended Fortran 95 textbook, "Fortran 90/95 Explained," is > 392 pages. "Teach yourself C++ Programming in 21 Days" is 814 pages. Kernighan and Ritchie is 272 pp. You can find far longer Fortran texts than M&R, and you can find far longer C texts than K&R, but it seems to me that K&R and M&R are pitched at similar levels for their respective languages. (They are both favorite books of mine, by the way.) > Item 7 is a half truth, and most of the disadvantages cited are actually > advantages. Fortran does have an official preprocessor: ISO/IEC 1539-3 > -- but it doesn't do macros, so Item 7 has a grain of truth in it. In > any case, it's not common to really really need a preprocessor because > Fortran programs are inherently more portable than C programs. Most > "portable" C and C++ programs consist almost entirely of preprocessor > macros and ifdef's. I have a 300,000 line Fortran 95 program that runs > on several platforms, and it doesn't have even one preprocessor directive > anywhere. I've never seen a large Fortran program that doesn't require some services that the language doesn't provide but that are provided by OS calls instead. Bindings are usually provided in C. Thus, must Fortran programs must call C, and the way this is done of course differs from platform to platform. In addition, the OS calls differ from platform to platform, so there may be #ifdefs in the C code. But these involve funtionalities that neither C nor Fortran supplies directly by dint of the language definition, so it's neither here nor there. I've literally never seen any large (or even small) C programs that "consist almost entirely of macros and ifdefs." Also, many -- probably most -- macros are programming-convenience macros which have no platform dependence. Van and I may have seen different Fortran programs (since his don't seem to have to call C) and different C programs (since his seem highly platform-dependent). I'm curious where the platform-dependence arises, outside of OS calls, though. C++ is a different story; C++ has only recently been standardized, and standard-conforming compilers are still not as ubiquitous as for Fortran or C. Hence #ifdefs. I'm curious how Van handles platform-variation of KIND parameters (assuming he needs to do this). > ...Sure, C > processors check references to functions against their prototypes, but > the prototype is separate from the function body; I don't know of any C > processor that checks prototypes against function bodies. I've never seen one that doesn't. If you have a prototype in a .h file, and that .h file is visible in the .c file where the function is defined, I get a function/prototype mismatch. Maybe "never seen" is an exaggeration, and I've not done a broad survey; but I just checked on IRIX and AIX, using the native C compilers, and on Linux with gcc, and all of these flag the mismatch explicitly. > Although item 9 is sort-of true (Fortran 77 programs are frequently > faster than equivalent Fortran 90 programs), it's also misleading; > Fortran 95 programs are usually a bit faster than equivalent C programs, I have never seen more implementation-to-implementation variation in performance than I have seen in F95 performance relative to F77 performance when F95 syntax is used. I've spent days trying trying to find constructs that will work reasonably well on all machines. And these were all UNIX! At times, I've reverted to old F77-style do-loops, instead of array notation, to get things to work reasonably well across the board. The point is that (as I've heard is the case in C++ as well) it takes a great deal of understanding of what is really going on under the hood to avoid shooting yourself in the foot. There are some things like this even in F77; for instance, programmers know that when traversing a 2D array using nested DO-loops, the row index should vary in the inner loop. There are many more things like this to be aware of in F95, and some of them are rather subtle. -P.