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

Internet Message Format | 1992-08-30 | 5.6 KB

Xref: sparky comp.edu:1410 comp.lang.fortran:3283 comp.lang.misc:2806 comp.arch:9094 sci.math:10701
Path: sparky!uunet!destroyer!gatech!rutgers!cbmvax!jesup
From: [e-mail] (Randell Jesup)
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: 30 Aug 92 00:18:29 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: [e-mail] (Randell Jesup)
Organization: Commodore, West Chester, PA
Lines: 93

[e-mail] (Herman Rubin) writes:
>>>>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.

>>     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.

    I think whoever wrote that last paragraph is quite correct.  One
should also remember that scientists are programmers of necessity: they
program because they have to, not because they're good at it or (generally)
like to do it.  This certainly doesn't improve the quality of the code,
let alone the maintainability...

>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.

    So?  That's a lot of why they exist.  They weren't created solely to
make life easier for physicists.  (Not that that's an invalid thing to do -
but your statement implies that all else is unimportant.)

>  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.

    Intervening in compiler output (as you call it) is at best dangerous,
doubly so for someone whose training isn't in software.  With highly optimising
compilers, when wading through compiler output I'll often say "that move is
useless", and then find out 50 instructions later it was highly useful.  With
heavily pipelined processors it's easy to produce subtle bugs, since things
don't always happen in the order they appear to from the list of instructions.
Etc.  If you need to write in assembler, do so, don't try to sneak behind
the back of other tools - you'll save yourself a lot of grief.

>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 what are these?  I've never heard a suggestion from these people
(I think); give examples (and make them apply to more than just number-
theory research).

> 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.

    It's mainly difficult because programming in assembler is fundamentally
more difficult - that's why we invented higher-level languages.  It's also
more difficult on most architectures because few people do it, therefore few
people bother to write better tools.  Processors that are primarily programmed
in ASM, such as the AT&T DSP3210, have very readable assembler syntax (for
an assembler) - it almost reads like C.

>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.

    I don't even want to _think_ about how hard that would be to deal
with...  There is a lesser alternative: link functions from different
languages together.  If you want to be really sick, make each line a "function"
and use some sort of preprocessor to build it by compiling each separately.
I don't think you'd be pleased with the results, though.

>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.

    Not every language is appropriate for every job, which is what I
think people told you last time this came up.  If there are specific problems,
give examples.  Also, I suspect that a large part of it is that (not
suprisingly) scientists don't want to learn N languages, they want a kitchen-
sink that does it all, AND they want it to be simple, AND they want it to
generate the tightest code theoretically possible.  This is like the old
cliche: fast, small, soon, pick any 2.  Those requirements are pretty close
to contradictory (certainly wanting all of them will greatly increase to
cost to produce any such compiler, if it can be done at all).

--
"Rev on the redline, you're on your own; seems like a lifetime, but soon it's
 gone..."  Foreigner
-
Randell Jesup, Jack-of-quite-a-few-trades, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, [e-mail]  BIX: rjesup
Disclaimer: Nothing I say is anything other than my personal opinion.