Structured design, goto's, and the holy grail

[Richard Harter]

In article <11528 at brl-adm.ARPA> dsill at NSWC-OAS.arpa (Dave Sill) writes:
>In article <22580001 at uxe.cso.uiuc.edu> mcdonald at uxe.cso.uiuc.EDU writes:
>>[Doug Gwyn, I believe, writes:]
>>>Actually, inter-module communication via global data is contrary to
>>>well-established structured design principles.  It should be used
>>>sparingly or not at all.
>>
>>Bullshit. Inter-module communication via global data is probably the most
>>potent method (to the programmer, not internal to a compiler) available
>>for both space and time optimization. Particularly space.

	Interesting issue.  There is a school that holds that inter-module
communication via global data is undesirable (strong, unstructured coupling.)
This school is wrong.  If procedure invocation is strictly heirarchical,
and all communication is via parameter sequences, then there are large
classes of programs which effectively cannot be written.  If procedure
invocation is non-heirarchical (i.e. you can call a routine from anywhere)
and you can have variables remembered from one invocation to the next,
then a simulation of global data is trivial.

	Heirarchical structure and data localization lead to clean
comprehensible software, when they are applicable.  Some have concluded
that all software should be written this way.  The position is an error;
there are (demonstratably) large classes of programs where this type of
structure is not effective.  

	The problem with global data, the goto, the procedure that can
be called from anywhere, et al, is that these are primitive constructs
that do not have structure associated with them.  The fundamental problem
is lay out principles of structuring that can be used in general, and not
merely in a restricted subclass of problems.

>Yeah, structured design has a habit of outlawing some of the most
>powerful techiques, e.g. the "goto".

	This particular statement is false in its implications, although
technically true.  There is a definite heirarchy of strength of control
structure constructs, running as follows:

(1)	if-then-else and while loops
(2)	forever loops with conditional escapes
(3)	conditional goto's
(4)	subroutine call/return
(5)	computed goto's (case statement)

Stength here means that there are programs which can be written using a
higher level construct which cannot be written using only lower level
constructs with paying either exponential penalties in space or logarithm
penalties in time.

	Forgoing the goto means, at most, loss of micro efficiencies as long
as one retains (4) and (5), which most structured programming advocates do.
The implication of the quoted sentence is that "power" is unstructured and
therefore "bad".  It is not the power of the goto that is "bad" -- there are
more powerful constructs -- it is its obscurity.

	It should be noted that procedure invocation has the same problem
as the goto -- you cannot tell, from the code within the procedure how
you got there.  Modularization is often cited as an important programming
principle, and it is.  But what it really does is push the problem up the
scale.  When you have hundreds or thousands of modules, you have the same
kinds of problems as when you have hundreds or thousands of statement numbers.


>For some odd reason, the
>proponents of structured design seem to feel that it's important to
>make code easy to understand, modify, and maintain.

	And have you stopped beating your wife?  One might well agree
that it is desirable to make code easy to understand, modify, and maintain,
and yet believe that the proponents of structured design offer a pseudo
solution that makes the objective harder to attain because  their 'solution'
is based on a fundamental misunderstanding of the problem.  Or, to put it
bluntly, replacing reason by religion may get you to Heaven, but it is not
the way to produce good software.  [Note: I do not necessarily endorse this
view nor oppose it.]
-- 

In the fields of Hell where the grass grows high
Are the graves of dreams allowed to die.
	Richard Harter, SMDS  Inc.