NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/lang/fortran/3235

Text File | 1992-08-27 | 3.2 KB | 69 lines

Newsgroups: comp.lang.fortran
Path: sparky!uunet!usc!zaphod.mps.ohio-state.edu!caen!hellgate.utah.edu!lanl!cochiti.lanl.gov!jlg
From: [e-mail] (Jim Giles)
Subject: Re: scientists as programmers
Message-ID: <[e-mail]>
Sender: [e-mail]
Organization: Los Alamos National Laboratory
References:  <[e-mail]>
Date: Thu, 27 Aug 1992 18:04:14 GMT
Lines: 57

In article <[e-mail]>, [e-mail] (Edward J. Hartnett) writes:
|> [...]
|> I think I should have been more clear when I said that scientists are,
|> in general, not as good programmers as professionals. [...]

People who write scientific/numerical programs for a living (instead
of as an adjunct to their scientific work) *ARE* professionals.  Yet,
their background is real science, not computing "science" (because no CS
type would even understand the problems).

|> [...]
|> If I could sit down all those scientists in a room and tell them one
|> thing, it would be that in all my experience programming, nothing is
|> more worthwhile than documentation. Particularly with science, if it's
|> not documented, it's almost useless, and will be completely useless
|> whenever it's handed to someone other than the original programmer.
|> Why? Because with science you have to KNOW what's going on in the
|> code. A small mistake can EASILY skew scientific results. And the time
|> invested in organization and documentation is more than repaid again
|> and again.

However, too many CS types view documentation as an end rather than
a means - that is, they write comments which do not elucidate:

      x++;  /* add one to x */

A good document consists of an abstract description of what the code
does, an abstract description of the algorithm which is being used, its
numerical properties, its speed (using big O notation if more precision
is not available).  The code itself has only a *few* imbedded comments
which indicate the correspondence of the code to the abstract algorithm.
One should not try to explain the algorithm *with* interspersed comments,
nor should one merely restate in english what the specific statements do
(if you can't read the language, take a tutorial).

Too often, the CS style documentation contains headers which name
the programmer, give the date of completion of the code, the date
of the last modification or bugfix, the language used (as if you
couldn't tell by looking at the code itself), and some joke about
known bugs that the author will *soon* fix (though the last mod
was years ago and the author has since left).  The author then
tries to explain the algorithm with interspersed comments *in* the
body of the code - and fails to write *either* a good description
of the algorithm *or* a good code.  But it's "fully documented"
by the criteria they were tought in school.

|> [...]
|> I guess it's exactly the same with professional programmers; I wasn't
|> convinced of this until I ended up with a job working on someone
|> else's code, [...]

Gee, in *all* my jobs, for 20 years, I've had to work with someone
else's code.  The dreaded "someone else's code" problem is commonplace
in programming.

--
J. Giles