Path: utzoo!mnetor!uunet!nuchat!steve
From: steve@nuchat.UUCP (Steve Nuchia)
Newsgroups: comp.software-eng
Subject: Re: Cynic's Guide to Software Engineering, part 3
Message-ID: <985@nuchat.UUCP>
Date: 30 Apr 88 18:38:42 GMT
References: <5752@well.UUCP>
Distribution: na
Organization: Public Access - Houston, Tx
Lines: 189

From article <5752@well.UUCP>, by shf@well.UUCP:
> I wrote a couple of image processing programs in Pascal once.  I was
> using a recursive algorithm, so I thought it would make sense to use a
> language that supported recursion (everybody knows you can't do

People who profess a preference for one kind of language over
others usually approach problems from a perspective appropriate
to that kind of language.  This colors their solution at a deep
structural level, leading to a mismatch if they are forced to
code the solution in some inappropriate language.  This is due
to the choice of solution architecture plus language, and has
much less to do with the combination of _problem_ and language
than is commonly believed.

I'm not trying to say that Mr. Ferguson is wrong, I'm generalizing.
But I do find his argument unconvincing - it amounts to proof
that he likes to program in FORTRAN by reasoning circularly from
the premise that he likes to program in FORTRAN. 


> This is a very good observation.  User interface isn't much of an issue
> for the scientists I work with, however, so that is not where the code
> is.  Most scientists are happy with something as simple as: 
> 	ENTER FILENAME: 
> A scientist's idea of a fancy user interface is being able to press
> return at the prompt to exit the program.  (This is a stereotype, to be

We are thinking of slightly different situations - your community
is using the programming language directly as a tool for data
manipulation, mine is (ultimately) building tools for production
data analysis.  The process is quite similar as far as it goes,
yours just stops when the code is thrown away or mutates out of
existance, mine becomes "supported".

[Much text describing the search for useful algorithms]

>>Sure, the program spends most of _its_ time in the scientific code,
>>but where are your programmers spending _their_ time?   ...
> 
> In a type of *interactive* software development cycle for which few
> languages are well adapted.

Again, we are looking at different phases of the process; you make
a very good point here.  I had glossed over the process by which
what I called the "algorithmic core" of my "supported programs".

>>Nuchia's law:  90% of any production program is doing data
>>        managment and user interface for the 10% that is
>>        doing the real work.
> 
> This is a good start, but what exactly is meant by a "production"
> program?  I also don't like the implication that user interface cannot
> be considered "real" work.  What about something like a CAD program
> which is nothing BUT user interface? 

As usual, the controversy is one of semantics :-)

CAD includes things like routers and design rule checkers and other
computationally intensive algorthms, but that is begging the question.
I was thinking of explicitly computational jobs when I wrote that, and
I meant "real" in its pop-culture sense - as in Real Programmers don't
write comments.  That is the sense in which your scientist might use
the word, "fancy users interfaces are useless - they don't do any
_real_ work".

By production program I mean one that has a user's manual, dozens
of users at several site, and is run orders of magnitude more often
than it is compiled.  Obviously this isn't a definition of the term,
but you get the idea.

>>... how good of a language is FORTRAN for
>>data management?  Pretty terrible.  It just doesn't have any
>>[etc]

> It's easy for us software types to blame the programming language; I
> mean, what could be worse than Fortran, right?  But I remind you that I
> wrote 'lexx,' 'yacc' and 'make' in Fortran with very little trouble. 

And some people do pretty amazing things in assembler, too.  Does
that make it right?

Ultimately the choice of program architecture is much more
important than the choice of language; all languages are
after all formally equivalent.  I find that FORTRAN restricts
my ability to manage system resources efficiently, and greatly
limits the portability of the resulting program.  That coupled
with the fact that I don't do a whole lot of numerical work
myself leaves me very comfortable _not_ using FORTRAN.  Diffirent
situations lead to different choices.

> This is Vax Fortran, an extension of FORTRAN-77 with 31 character
> identifiers, structured control flow and structured data types, among
> other things.  I've done recursion, linked lists, string manipulation
> and even dynamic memory allocation in Fortran.  I'm not pushing Vax

"and even" dynamic memory allocation?

shhh!  my case is resting.

> Fortran as some kind of True and Great language, but I AM suggesting
> that the source of some of the problems Steve addresses may be a result
> of more than JUST the choice of programming language. 

On that I agree completely.

> The "scientific" programs which start small and grow, such as the ones 
> that Steve refers to, are rarely planned.  Rather they evolve out of the
> kind of interactive development (i.e. hacking) that I described.  For
> cases where the program was actually designed in advance, such as my
> 'lexx,' 'yacc,' and 'make' utilities, Fortran was a workable choice. 

Excelent points.  My point in relation to the unplanned growth
was simply that at some point the program gets so large, and
is doing so many unexpected things, that the original language
choice is no longer appropriate.  Common practice does not have
a provision for recognizing and dealing with that threshold; I
am proposing that making such a provision explicitly would be
a good thing.  Secondarily I'm arguing that having that mechanism
in place would reduce a lot of the motivation for the language wars.

The point about FORTRAN being workable with advance planning says
a great deal more about the value of planning that it does about
the fundamental suitability of FORTRAN for systems programming.

> Some might argue that bad C code is better than good Fortran code, but I

Some might; I'm not one of them.

> don't find this to be the case, and I strongly suspect that those who
> say this don't really know how to recognize a good Fortran program. 

Or a bad C program.  FORTRAN is (was - 9X is a mess) a much simpler
language in some ways than C.  Bad FORTRAN programs are bad because
of scale, aliasing problems, and poor choice of names, primarily.
Bad C programs can have all of those problems, along with additional
aliasing brought about by pointer abuse, preprocessor abuses, and
unimaginably tortuous control structures (C does have goto, and bad
programs use it, but that is the least of the control structure problems
in a really bad C program).

An important concept in program quality is "referential transparency";
the idea that the meaning of a fragment should be as clear as possible
without reference to distant passages.  In my opinion, no program is
truly world-class bad unless it grossly lacks referential transparency.
Of course both C and FORTRAN have mechanisms by which a dedicated
hacker can obscure the meaning of his code; arguing about which is
better on the basis of bad programs is silly.  (and besides, FORTRAN
might win, and we can't have that!  :-)

A skilled and disciplined programmer can produce high quality
programs in any language.  No language can prevent poor code.



Now we dive into a discussion of user interfaces.

> do something as simple as draw a line.  Experience with these tends to
> make me shudder when I see someone refer to a building a GIANT user
> interface library. 

Once again we are seeing things differently because we are looking
at different things.

> The best library interface, as well as the most useful user interface
> library for Fortran programs I've even seen happens to be the same
> library.  It is called GIRL (Generalized Input Routine Library) and the
> basic programmer interface consists of ONE subroutine call.  The 
> programmer can do something like:
> [description of prompt generator] 

Simple tools are just the thing for simple results, and the prompt
handler looks like just the thing for short-lived programs.  What
I had in mind were things like the Macintosh Toolkit or Suntools
or similar graphical interactive user interface environments.  Even
the typical spreadsheet or data entry screen needs significantly more
sophistication than your prompter can give, and that additional complexity
inevitably impacts the design of your code.



The remainder of Mr. Ferguson's article contains very good data
on his experiences with growing programs, exactly the kind of
information I had asked for.  Thank you!


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