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

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

Xref: sparky comp.edu:1439 comp.lang.fortran:3322 comp.lang.misc:2836 sci.math:10767
Path: sparky!uunet!usc!wupost!waikato.ac.nz!aukuni.ac.nz!ecmtwhk
Newsgroups: comp.edu,comp.lang.fortran,comp.lang.misc,sci.math
Subject: Re: Scientists as Programmers
Message-ID: <[e-mail]>
From: [e-mail] (Thomas Koenig)
Date: Tue, 1 Sep 1992 04:48:40 GMT
Organization: University of Auckland, New Zealand.
Lines: 42

I think there is quite an important distinction to make when you look at
the type of programs scientists write: what it is for.

Personally, I have encountered four types of programs.

One is the "one - shot" program, which is typically written to show that
it is safe to neglect X, or that Y holds. These programs are usually
optimized toward development time minimum: just get it running as fast
as possible, no matter how efficient it is, or what dirty tricks it
uses. For these programs, documentation is almost unheard of, and
persuading people to write them "cleaner" is probably going to be
impossible.

The second class of program is the "production version", which you
may need to run quite often, say once for every experiment you do.
If efficiency is indeed critical, people may spend some time on
optimizing the code; with some luck, they may even document it.

The third class of program is the general libary, which implements
commonly (or not so commonly) used algorithms. Usually, people who write
these use professional software development methods, and probably few CS
purists would find fault with their methods (except that they usually
use FORTRAN :-)

The fourth group is that of data aquisition programs. These could
probably benefit most from CS, and yet the experimental scientists who
are usually stuck with writing them for their own rigs are least likely
to have any experience with programming. They might even have to use
a language like GWBasic because the hardware can only be accessed by a
vendor - supplied library.

There is, however, another aspect to this. Scientists usually view a
program as a means to an end. Any time they spend on the niceties of
program documentation, code cleanup etc. is going to come straight out
of the time when they could have written that other publication or made
these four extra experiments to check out that exciting new theory.
Making life easier for someone who might someday come across a similar
problem is not going to be high on their list of priorities.
--
Thomas Koenig, [e-mail], [e-mail]
The joy of engineering is to find a straight line on a double logarithmic
diagram.