Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!mailrus!husc6!ukma!psuvm.bitnet!uh2
From: UH2@PSUVM.BITNET (Lee Sailer)
Newsgroups: comp.software-eng
Subject: Re: Cynic's Guide to Software Engineering, part 3
Message-ID: <39544UH2@PSUVM>
Date: 17 Apr 88 21:28:23 GMT
References: <1950@rtech.UUCP> <945@nuchat.UUCP>
Distribution: na
Organization: Penn Sate Erie--School of Business
Lines: 58

In article <945@nuchat.UUCP>, steve@nuchat.UUCP (Steve Nuchia) says:
>
>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.
>

This is a very good point.  Here's a testimonial---in the early 70's I
supported an in-house statisitcs package that was used primarily
for multiple regression.  The regression code was lifted from early
BMD (no P back then) code, and was 155 lines of FORTRAN.  The total
package was over 5000 lines.  User interface, idiot proofing,
a transformation language, file management, etc, took up the rest.


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

Except for COMPLEX variables, I have never been able to see why FORTRAN
is better than C, Pascal, ALGOL, etc etc etc for "scientific" programming.

I have always been bothered, too, that by not putting a Complex type
and its associated operators in the language, C and other modern
languages have thumbed there noses at physical scientists.