NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/edu/1326

Internet Message Format | 1992-08-31 | 5.8 KB

Xref: sparky comp.edu:1326 comp.lang.fortran:3149
Newsgroups: comp.edu,comp.lang.fortran
Path: sparky!uunet!cs.utexas.edu!zaphod.mps.ohio-state.edu!usc!sol.ctr.columbia.edu!destroyer!news.iastate.edu!IASTATE.EDU!btd
From: [e-mail] (Benjamin T Dehner)
Subject: Re: Small Language Wanted
Message-ID: <[e-mail]>
Sender: [e-mail] (USENET News System)
Reply-To: [e-mail] (Benjamin T Dehner)
Organization: Iowa State University
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 25 Aug 1992 18:41:43 GMT
Lines: 98

In article <[e-mail]>, [e-mail]
(Edward J. Hartnett) writes:
> In article <[e-mail]> [e-mail]
(Randy Crawford) writes:
> >In article <[e-mail]>
[e-mail]  (John E. Davis) writes:
>
> >>Yes
> >>Fortran is still superior to C for what it is intended to do: Numerical
Work.
> >>Anyone who ``regularly lambast physicists for using "old" languages like
> >>Fortran'' is a little ignorant in my view.
> >
> >On a single statement basis, I'd agree: FORTRAN has it over C in expressing
> >numeric computations (you forgot to mention the problems C has in evaluating
> >expressions having mixed numeric types).  But if you've ever attempted to
> >modify or even read a large FORTRAN program, you've experienced what I have
> >-- a rat's nest.  I don't believe it's possible to write modular FORTRAN
> >code: at least, I've never seen it.  And unless FORTRAN 90 eliminates
> >constructs like computed gotos, FORTRAN code will never become structured or
modular.
>
> I must disagree. While it is true that C is more often written more modular,
it is
> certainly possible to write well-behaved FORTRAN code. I think that
> what you are seeing is not that FORTRAN lends itself to rotten code,
> but that scientists usually write bad code, in whatever language they
> use. No offense to scientists, but I have rarely if ever seen a
> scientist who was a good programmer. They may know the language inside
> out, they may be able to whip up their application in a day that would
> take me a week, but take a look at it and you'll barf. Partly I think

    As a scientific programmer, I have no choice but to agree with the
above statement.  I am curently working on a program that was originally
written in the late 1960's, and has since been heavily modified.  The original
code had almost zero documentation, and almost none of the hordes of people
who have gotten there hands in it since have explained what they did or what
they are trying to do.  The only good thing about the code is that it is highly
structured with many subroutines, so that I can look at one part at a time.

> that this is because they have other things to worry about (like the
> purpose of the application, rather than implementation details),
> partly because it's part of the myth of science that scientists are
> smart, and so they think "I don't need to write simple, clear code,
> I'm smart enough to figure it out if I have to," and a big part of it
> is that they have either never studied programming, or they studied it
> so long ago that it was before modern programming, and the benifits
> thereof, were ever heard of. Essentially, they never know what they're
> missing. They think code is supposed to be badly documented, poorly
> structured, and difficult to understand.

    No, often the code is not really meant to be used by other people.
Then when it does start getting spread around, ...

> I never use common blocks myself, ditto global variables (are their
> global variables other than in common blocks?). Subroutine arguments
> are always passed by reference, never value (how do you pass by
> value?). User defined data types (i.e. structures) are available in
> many implementations of FORTRAN (e.g. Sun), if you don't insist on
> standard FORTRAN 77, ditto for loop constructs. I have to say right
> here that I am talking about FORTRAN with extensions. I would never
> like to write in strict standard FORTRAN. But I think that commercial
> applications are rarely written in FORTRAN, and too many FORTRAN
> programmers don't use the language extensions, althought there is
> little chance they will ever have to port their code, and a good
> chance that if they do, the other machine will support the same or
> similar extensions.

    The code I have mentioned above has been beat into as standard of
Fortran as could be managed.  Anything nonstandard/system dependant is put
into a special set of subroutines.   We can now routinely pass the code back
and forth from an Ultrix system to a VMS system, and by adding the special
subroutines -- about a 100 line file (out of about 12700 for the rest of the
program) compile and run with no problem.

> >
> >I think the real advantage that C has over FORTRAN (and Pascal has over C)
is
> >especially among undisciplined numerical programmers, where the "better"
> >language allows sufficient expressiveness to solve the problem, yet less
> >opportunity to write bad code.  And it's easier for "part-time" programmers
> >to write bad code in FORTRAN than in C.

    No.  C is such a terse language it is very easy to write bad code.
It's your programming style and how much effort goes into making the code
legible that counts, which, as mentioned above, scientists who mostly used
Fortran tend not to do.

> Perhaps true, but learning C is a lot more difficult than learning
> FORTRAN. Plus you're just not going to get around those thousands of
> man-years of extant FORTRAN code!


-----------------------------------------------------------------------------
Benjamin T. Dehner    Dept. of Physics and Astronomy
[e-mail]       Iowa State University
                      Ames, IA 50011