Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!think!husc6!cca!g-rh
From: g-rh@cca.CCA.COM (Richard Harter)
Newsgroups: comp.lang.c
Subject: Re: Structured design, goto's, and the holy grail
Message-ID: <23816@cca.CCA.COM>
Date: 30 Jan 88 11:50:57 GMT
References: <11528@brl-adm.ARPA> <23777@cca.CCA.COM> <10381@mimsy.UUCP>
Reply-To: g-rh@CCA.CCA.COM.UUCP (Richard Harter)
Organization: Computer Corp. of America, Cambridge, MA
Lines: 84

In article <10381@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>In article <23777@cca.CCA.COM> g-rh@cca.CCA.COM (Richard Harter) writes:
>
>>	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.

>Exactly.  The structure must be imposed externally:

>>The fundamental problem is lay out principles of structuring that
>>can be used in general, and not merely in a restricted subclass of
>>problems.

>and one way to impose that structure is to reduce the number of
>such constructs to something manageable.

	I'm not sure what you meant to say here.  If you mean number
as 'number of kinds of such constructs' then I would say no -- one
such construct is sufficient if it is used liberally.  If you mean to
say that the number of instances in a program of 'unstructured
constructs' should be small, then who can argue?

	However, I will contend that the 'numbers' issue is not the
point.  The nice thing about eliminating goto's is that one can eliminate
them without pain.  (In new code, at least.)  The constructs of structured
programming suffice for writing code quite nicely; I would say that they
make it rather more pleasant and easier.  However (assuming that one
breaks thing up into modules of decent size) the issue of flow control
constructs is less important than it is made out to be -- the problems
and issues don't get out of hand because their arena is so small.

	Large scale problems are fundamentally different.  Let me give
a typical example.  We have a program which accepts a file name as an
argument; this is the name of a file which to a report will be written.
In the program there is a package which handles the report; there is
also a routine which processes the arguments.  Who owns the data and
how do we store it?

	We would like the argument cracker to be pure; it shouldn't
know what the file name is about; we want it to send a message to the
report package, here is a file name that you expect.  So far, so good.
But now, we need to give the argument cracker the destination of this
file.  Somebody has to do this.  The problem created by the connection
between these two packages has been pushed back a level, but it remains.
Our program also has a file manager, which keeps track of the files
that the program is using.  Etc.

	So we have all these connections between different packages
that have to know something about this data item.  Maybe we make a
little package just to handle this data item.  Fine.  But then we
need protocols between the various packages that need the data and
the package managing the data.  Which implies that the various packages
have to know about a lot of protocols.

	The point of this dadaist excursion into programming is that
a large system is composed of multiple interconnected subsystems.
The problem of 'global data' is a manifestation of the problem of
organizing large systems.

>>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.
>
>Sure.  Then the problem becomes one of heirarchically making clusters
>of modules, with rules for interaction between clusters, and so
>forth.  I think both Ada and Modula-2 have problems here; indeed,
>I know of no language that provides a really decent solution.
>(Look at the problems people have building pipelines on Unix
>machines, for instance.  If each utility is considered a module,
>we have hundreds of modules available.  Since a utility that
>consists of a pipeline is simply another utility, what we did by
>making one was to make the module space bigger!)

	I think the key line here is "I know of no language that
provides a really decent solution.".  I suspect that one has to
go beyond the concept of a programming language to get a decent
solution.  Actually, Unix has done rather well along these lines.
It does provide a common environment and set of interfaces that
works fairly well -- up to a certain size.
-- 

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