jav8106@ritvax.isc.rit.edu (Doctor FORTRAN) (11/27/90)
It is a proven fact that nobody actually programs in C. It is only possible to
hack in C. :-)
Let's face it -- C has all kinds of bells and whistles, such as structures,
unions, boolean manipulations, dynamic allocation, etc., but it is a real dog
to work with. For one thing, it simply isn't as portable as FORTRAN. A short on
one machine is something else on another. The whole thing was really a
heinous hack job foisted off on a bunch of computer-science types who simply
had to have those bells and whistles -- and took it to heart in spite of its
glaring inadequacies, which were different from FORTRAN's glaring inadequacies.
Now those aforementioned bells and whistles are being addressed by the 9X
standard as well as the DoD extensions. Has FORTRAN been slow to adopt these
goodies? Of course! But anyone who has any experience at all with the national
standardizing process (I have served on a technical subcommittee of a working
group) can tell you that it is far easier to introduce something completely new
(such as a new langauge) than modify something which already exists as a
standard. How did FORTRAN 77 come about? Vendors started adding extensions to
FORTRAN IV (sometimes referred to as FORTRAN 66) in order to satisfy market
demand. It finally reached the point when the extensions were so numerous that
a revision of the standard was prudent. The proposed 9X standard evolved from
the existing 77 standard in the same way.
FORTRAN is growing, adapting. C has remained fairly static (no pun intended)
since its introduction. The biggest difference between the first and second
editions of K & R deals with function prototypes. Why doesn't C evolve into
something more attractive, as FORTRAN has? Possibly because the problems with C
are more intrinsic to the langauge itself -- Many of C's problems cannot be
solved by introducing extensions, but rather by changing the langauge itself.
This is difficult to accomplish without introducing serious compatibility
problems.
Of course, C is fairly new in comparison to FORTRAN. If our experience with
FORTRAN is any indication, 10 - 15 years elapse between standard revisions.
Perhaps 10 years from now a more usable C will have evolved. But I doubt that
it will have changes which are as significant as those introduced to standard
FORTRAN in 1977 and in the current proposed standard.
C ==========================================================================
C === This subroutine will write a signature at the end of a posting.
Subroutine Signature
Write (*, 101)
101 Format (1H1, 'Doctor FORTRAN', /, ' Master of the Realm', /,
1 ' Reply: jav8106@ritvax.isc.rit.edu')
Return
Endttw@lanl.gov (Tony Warnock) (11/28/90)
It's subroutines such as the following that make
me prefer Fortan to C.
SUBROUTINE mmkji (a,b,c,n1,n2,n3,m)
INTEGER n1, n2, n3, i, j, k, m
COMPLEX a(m,n1,n2), b(m,n2,n3), c(m,n1,n3)
DO 30 j=1,n3
DO 20 i=1,n1
DO 10 l=1,m
c(l,i,j)=(0.0,0.0)
10 CONTINUE
20 CONTINUE
30 CONTINUE
DO 70 k=1,n2
DO 60 j=1,n3
DO 50 i=1,n1
DO 40 l=1,m
c(l,i,j)=c(l,i,j)+a(l,i,k)*b(l,k,j)
40 CONTINUE
50 CONTINUE
60 CONTINUE
70 CONTINUE
ENDjohn@ghostwheel.unm.edu (John Prentice) (11/29/90)
In article <1990Nov26.171823.4008@isc.rit.edu> jav8106@ritvax.isc.rit.edu writes: > >Let's face it -- C has all kinds of bells and whistles, such as structures, >unions, boolean manipulations, dynamic allocation, etc., but it is a real dog >to work with. For one thing, it simply isn't as portable as FORTRAN. A short on >one machine is something else on another. The whole thing was really a >heinous hack job foisted off on a bunch of computer-science types who simply >had to have those bells and whistles -- and took it to heart in spite of its >glaring inadequacies, which were different from FORTRAN's glaring inadequacies. > I would like to quote Jim Giles concerning essentially this point. Fortran's sins are sins of omission. C's sins are sins of commission. John Prentice Amparo Corporation Albuquerque, NM
dgh@validgh.com (David G. Hough on validgh) (11/29/90)
There have been recent statements that functions like sqrt() are equivalent in Fortran and C. This is incorrect. In C, sqrt() is simply a function invocation. It has no known semantics unless #include <math.h> has been seen, in which case ANSI-C knows that it is a double-precision function of a double-precision argument. Thanks to the default conversions, you can use sqrt on float arguments with correct results, but they may take twice as long to compute as necessary if you really meant sqrtf(). sqrt() won't work on long double arguments unless long double == double. In Fortran, sqrt() is a generic intrinsic function, really an operator like +. Its semantics are known to the compiler. The precision of the sqrt operation can match that of the operand. As mentioned by others, ANSI-C defines exception handling for the sqrt() function and not for operators. On high-performance implementations, error checking, involving a conditional test and branch, can take as long as the sqrt operation itself, even if performed inline. System V implementations are worse, requiring an external call to matherr(), although this will be removed in a future version of SVID. -- David Hough dgh@validgh.com uunet!validgh!dgh na.hough@na-net.stanford.edu
henry@zoo.toronto.edu (Henry Spencer) (12/02/90)
In article <219@validgh.com> dgh@validgh.com (David G. Hough on validgh) writes: >There have been recent statements that functions like sqrt() are >equivalent in Fortran and C. This is incorrect. > >In C, sqrt() is simply a function invocation. It has no known >semantics unless #include <math.h> has been seen, in which case >ANSI-C knows that it is a double-precision function of a double-precision >argument... Unfortunately, this too is incorrect. In the absence of #include <math.h>, "sqrt" remains reserved for system use as an external name, and all bets are off if a program uses it for that purpose itself. (It can, however, be used as an internal-only name, e.g. a static function.) In the presence of #include <math.h>, it is *not* known to be a double-precision function of a double-precision argument; that is merely one of several possibilities. What is known is that you can call it as if it were one. It may well be a macro whose internals invoke compiler-specific magic, rather than a function invocation of any kind. >Thanks to the default conversions, you can use sqrt on float >arguments with correct results, but they may take twice as long to compute >as necessary if you really meant sqrtf(). There is no programming language that can remove the programmer's ultimate responsibility for efficient code. >sqrt() won't work on long double arguments unless long double == double. However, sqrtl() is reserved for future use for this purpose, and people supplying a useful `long double' type would presumably supply one. >In Fortran, sqrt() is a generic intrinsic function, really an operator like +. I don't recall this in the existing Fortran language (although I have not used Fortran 77 very much and might have missed it). If we're talking about future languages, like Fortran 20xx (called Fortran 9x by some optimists), the folks over in comp.lang.c++ can fill you in on a descendant of C, already in widespread use and in the works for standardization, which permits such things. >As mentioned by others, ANSI-C defines exception handling for the sqrt()... Now, *this* is a real issue, and one I'd forgotten about. -- "The average pointer, statistically, |Henry Spencer at U of Toronto Zoology points somewhere in X." -Hugh Redelmeier| henry@zoo.toronto.edu utzoo!henry