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

Internet Message Format | 1992-08-29 | 3.8 KB

Xref: sparky comp.edu:1390 comp.lang.fortran:3259 comp.lang.misc:2794 comp.arch:9081 sci.math:10666
Path: sparky!uunet!gatech!purdue!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubin
From: [e-mail] (Herman Rubin)
Newsgroups: comp.edu,comp.lang.fortran,comp.lang.misc,comp.arch,sci.math
Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
Message-ID: <[e-mail]>
Date: 28 Aug 92 15:47:10 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail] (USENET News)
Organization: Purdue University Statistics Department
Lines: 56

In article <[e-mail]> [e-mail] (Marc Roussel) writes:
>In article <[e-mail]> [e-mail]
>(Doctor FORTRAN) writes:
>>In article <[e-mail]> [e-mail]
>>(Edward J. Hartnett) writes:
>>> [. . . . ] 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.

>>But I must disagree when you characterize
>>scientists as bad programmers. That's bigotry, and a stereotype to which I
>>must strenuously object.

>     It's not bigotry, it's a sociological generalization applicable to
>the vast majority of scientists who write computer programs.  You should
>see the things I've seen...
>     Edward wasn't trying to insult anyone.  He correctly identified the
>source of the problem:  Scientists think that any code that executes
>correctly and quickly is OK.  What it looks like and whether it would
>meet with the approval of CS weanies is completely irrelevant
>to us.  Of course, that also means that our "one-shot" code had better
>never need to be tweaked.

The problem is that the CS people are, in this sense, like the purissima
mathematicians (if it can be applied, it is time to work on something else.)
They concentrate on what no scientist is particularly worried about, like
making the printed output look neat, or even making life easy for the
compiler.  They talk about optimizing compilers, but when someone brings
up something which the current styles of optimization do not handle, they
still say that the programmer must not be allowed to intervene with the
product of the compiler, and things must be left to the compiler.

If we want to do good programming for scientists, both the hardware and
the software have to take into account what the scientists with imagination
can think of, not what those doing routine can envision.  The ideas of those
who make extensive use of the computer for number theory, for example, are
entirely ignored by both the hardware people and the language people.  And
it is almost official policy to make the use of machine language other than
through the inadequate high level languages at least very difficult.

Fortran is inadequate, Algol is inadequate, C, and even C++, is inadequate.
Even if a programmer can find a good way of mixing them, there is no
possibility of having one line in Fortran and the next in C.

Most good scientists can think of their problem, and how reasonable operations
can attack it.  But the languages do not facilitate this, and often even if
the features are present, they are in some obfuscated syntax.  Handling the
syntax problem alone would make for great improvement, but I see nothing in
this direction, and have asked for software to do this single job.
--
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: [phone]
[e-mail] (Internet, bitnet)
{purdue,pur-ee}!pop.stat!hrubin(UUCP)