NOT Educating FORTRAN programmers to use C

[Sean Fagan]

In article <14195 at lambda.UUCP> jlg at lambda.UUCP (Jim Giles) writes:
>> So, you don't consider PRINT, READ, WRITE, COS, SIN, etc., to be parts of
>> FORTRAN?  [...]
>Yes, I _do_ consider all the above features to be part of Fortran.  They
>are all _required_ by the existing standard.  The _proposed_ ANSI C
>standard on the other hand does not contain any such requirement for
>'str*()'.  Therefore, it is not an inherent part of the language.  

They *are* required, for *hosted* implementations.  Non-hosted
implementations aren't expected to run on the same system you're compiling
on; therefore, the library might not make a whole lot of sense.  Think about
it:  if you're writing something for an embedded controller (something most
people would pick C for instead of FORTRAN), you don't really *care*
whether or not strftime is in the library, do you?  If you're on a hosted
implementation, then the libraries *are required to be there*, just like in
FORTRAN.  Most people will not deal with non-hosted implementations, so it's
pretty much a moot point, except for those that know they're special
anyway.

Look:  I like C.  A *lot*.  I also like FORTRAN.  There are a lot of things
I'd prefer to do in FORTRAN than Pascal, or even C, on the right system (a
Cyber is a damnably good FORTRAN engine, as are Cray's).  However, on a UNIX
machine, I'm probably going to use C instead of FORTRAN (the compiler is
probably better, the library is probably designed to work with it instead of
any other language, etc.).  On a Cyber, again, I use FORTRAN, almost
exclusively (well, an occasional assembly routine).  Different systems,
different languages.

-- 
Sean Eric Fagan  | "If a compiler emits correct code purely by divine guidance
seanf at sco.COM    |  and has no memory at all, it can still be a C compiler."
(408) 458-1422   |           -- Chris Torek (chris at cs.umd.edu)
-----------------+ Any opinions expressed are my own, not my employers'.