Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!ucbvax!pasteur!ames!mailrus!umix!umich!mibte!gamma!ulysses!thumper!faline!bellcore!tness7!tness1!nuchat!steve
From: steve@nuchat.UUCP (Steve Nuchia)
Newsgroups: comp.software-eng
Subject: Re: Cynic's Guide to Software Engineering, part 3
Message-ID: <945@nuchat.UUCP>
Date: 16 Apr 88 03:26:19 GMT
References: <1950@rtech.UUCP>
Distribution: na
Organization: Public Access - Houston, Tx
Lines: 68

From article <1950@rtech.UUCP>, by daveb@llama.rtech.UUCP (Crack?  No thanks, I've got a new CD player):
> We have just barely gotten out of the "operating systems are written in
> assembler" mind set.  It is hard for me to believe that, for sake of
> argument, FORTRAN is incapable or even very seriously flawed in its
> ability to model physics problems compared to any of the likely
> alternatives.

FORTRAN is a very nice language for arranging to have arithmetic
FORmulas evaluated, andit is even ok (in its present form) at
organizing a moderately complex sequence of calculations.

The problem is, that isn't what most programs do.  In my experience
the text of most "scientific" programs begin life as some small
amount of FORTRAN embodying some algorithm - maybe as much as a
few thousand lines.  This much is as it should be.

Now, this little program starts to be _used_ for something.  It becomes
"supported", and starts to grow.  The algorithm doesn't grow.  What
grows is the data management and user interface cruft around the
central algorithm.  Since the whole wad is still in FORTRAN the
maintenance programmers have littered the algorithmic code with
flags and such to support all the new features, but by this time
the data management and user interface code outweighs the "scientific"
code by ten to one or better.

Sure, the program spends most of _its_ time in the scientific code,
but where are your programmers spending _their_ time?   Right.

Nuchia's law:  90% of any production program is doing data
	managment and user interface for the 10% that is
	doing the real work.

With that out of the way, how good of a language is FORTRAN for
data management?  Pretty terrible.  It just doesn't have any
of the semantics you need.  Sure, you can kluge around it,
but why?

User interfaces, if implemented properly, just consist of
a large state machine which calls a giant UI library.  The
state machine can be written in FORTRAN or BASIC or SWAHILI
or whatever you want, as long as some kind of conventional
structure is used - the nodes of the state graph should
all follow a stereotyped format to a greater or lesser
degree.

You wouldn't want to write the UI library in FORTRAN, but
thankfully I don't think there are very manu people left
who would insist that you do so.

What's the solution?  Let your scientific programmers code in
FORTRAN.  They're getting their work done, and you've got enough
work to do without going on a crusade to "save" them.  And of
course you get to take advantage of the available optimization
technology for the long-running core of the programs.  But
make your maintenance programmers learn and use a modern
language; pick one with a good interface to your FORTRAN
environment.

I have to admit that I haven't seen this tried on a significant
scale.  The ideas presented above have been forming in my mind
for a couple of years, and lately I've had an opportunity to
watch scientists produce programs, confirming much of what I
had thought.  Take it for what its worth, and I would appreciate
any evidence supporting or contradicting my positions.
-- 
Steve Nuchia	    | [...] but the machine would probably be allowed no mercy.
uunet!nuchat!steve  | In other words then, if a machine is expected to be
(713) 334 6720	    | infallible, it cannot be intelligent.  - Alan Turing, 1947