Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cwjcc!tut.cis.ohio-state.edu!osu-cis!dsacg1!dsacg3!vfm6066
From: vfm6066@dsacg3.UUCP (John A. Ebersold)
Newsgroups: comp.software-eng
Subject: Structured Programming
Summary: No existing software environment removes engineering tradeoffs.
Message-ID: <1328@dsacg3.UUCP>
Date: 9 Feb 89 14:34:38 GMT
Reply-To: vfm6066@dsacg3.UUCP (John A. Ebersold)
Organization: Defense Logistics Agency Systems Automation Center, Columbus
Lines: 61


Structured programming is currently being discussed in comp.unix.wizards.

To summarize the various comments (with apologies to the original posters):

Structured programming is a way for mediocre programmers to produce good
code; a way to prevent code from deteriorating into a tangled mess, etc.

Also, some programming environments or languages are good certain things
but not good at others.  Forcing a language to do something it doesn't
"naturally" do may be more trouble that it worth.

Pointers are not natural in Fortran - simulating them causes much work.
Other languages that have the notion of procedures without parameters -
simulating the parameters via global variables may impose some structure on
the code - but at what cost?  I did this once but it was NOT fun but I
thought it was worth the trouble.

These types of things are what Frederick Brooks calls the accidents
of software engineering.  In an article in IEEE Computer
Magazine last year Brooks write of the search for the magic bullet that
will slay the software development beast.  He concludes that while many
things can be done no "magic bullet" exists.

No software engineering, program generation environment, etc currently
exists that removes the need for humans to make requirements/design and
design/coding trade when building software.  We don't have a mind reader
that figures out what people REALLY want and writes the code for us.

I pose some questions?

Some people think a good design is more important than the language of
implementation.  A good design is essential but the language is important
also.

Can a good programmer write a good program in a bad language? Yes.

Can a bad programmer write a bad program in a good language? Yes.

Can a bad programmer screw up a good design? Yes.

Real case study (I was the project leader):
In a large software system, a kludge cannot be avoided (the real world is
often that way).

Do you isolate the kludge in one or two modules that
really don't (strictly speaking) need to know about the kludge 
or how to handle it?  The alternative is to put the knowledge of the
kludge in the twenty or so modules other modules.  I choose the former.

Stated another way: A well placed kludge can be considered elegant.

If these things have been discussed before, sorry.

If not, what are your thoughts?

-- 
John A. Ebersold, Unify Corporation @   Defense System Automation Center
osu-cis!dsacg1!dsacg3!vfm6066	     	Columbus, Ohio 		1-614-238-5923
The trouble with the world is that the stupid are cocksure	AV    850-5923
and the intelligent are full of doubt - Bertrand Russell.