Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!umd5!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: Structured design, goto's, and the holy grail
Message-ID: <10392@mimsy.UUCP>
Date: 30 Jan 88 14:36:42 GMT
References: <11528@brl-adm.ARPA> <23777@cca.CCA.COM> <10381@mimsy.UUCP> <23816@cca.CCA.COM>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 66

>In article <10381@mimsy.UUCP> I said
>>and one way to impose that structure is to reduce the number of
>>such constructs to something manageable.

In article <23816@cca.CCA.COM> g-rh@cca.CCA.COM (Richard Harter) replies:
>	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?

I meant the latter.  (Nice not to have to argue. :-) )

>However, I will contend that the 'numbers' issue is not the point.

But I think, ultimately, it is!  Borrowing your example:

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

(and, being small, they remain comprehensible.)

>Large scale problems are fundamentally different.

I think not:

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

And when the number of protocols expands beyond some limit, it
becomes incomprensible as a whole---just as when the number of
labels in a Fortran program gets out of hand, the structure of a
module dissolves.  While loops and case statements and such provide
a way to keep the structure of modules, without having to break
them into sand-grains rather than building blocks.  Object oriented
message passing models provide a way to add structure to global
interactions, but someday, someone will wonder whether to use a
SemaphoredQueue or a MonitoredSparseArray, or was there a better
type...?  Time to root through the 15 GB index of possible datatypes!

>The problem of 'global data' is a manifestation of the problem of
>organizing large systems.

I think no one really knows how to do this, no matter *what* the
system, when it gets truly enormous.  Large companies and governments
have the same problem.  Hierarchical [my fingers want to type
`heir'!] breakdown works well up to some size, but eventually the
sheer number of levels in the hierarchy becomes a problem.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris