jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) (01/03/91)
In the book, _Principles of Functional Programming_, by Glaser, Hankin, & Till, it is stated, "the notion of global state that may change arbitrarily at each step of the computation has proved to be both intuitively and mathematically intractable." In classical structured programming, the use of global state was discouraged, but programmers tended to be undisciplined, and there never was any clear philosophy on how storage should be structured in a program. The solution offered by functional programming is to eliminate all state from programs. A functional program passes data around without ever storing it anywhere. In object-oriented design, the approach is to eliminate all shared data areas, and to encapsulate any state so that all access to it is localized. The argument of advocates of functional programming is that if you don't have a program state (i.e. side effects), you don't have to worry about anything going wrong. The advocates of object-oriented design say that it's easier to design and maintain a program where you nail down the state of something in an object, and keep the state encapsulated so that it can't be touched. Is the issue of program state really the crux of the issue of program tractability and of control of complexity in software engineering? It seems to me that the ability to localize program state is an essential requirement, but I don't see why it should be necessary to eliminate it altogether, as in functional programming. -- John Dudeck "If it's Object Oriented then by jdudeck@Polyslo.CalPoly.Edu definition it's A Good Thing". ESL: 62013975 Tel: 805-545-9549 -- D. Stearns
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (01/03/91)
In article <27823155.211e@petunia.CalPoly.EDU> jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) writes: > In the book, _Principles of Functional Programming_, by Glaser, Hankin, > & Till, it is stated, "the notion of global state that may change > arbitrarily at each step of the computation has proved to be both > intuitively and mathematically intractable." That's a nice religion but it's simply not true. I am working on a formal, quite mathematical, definition for the semantics of my Q language. Q supports nonpreemptive threads and some amount of parallel processing. It supports data hiding even better than Ada---Piercarlo, if you're reading this, I stole your ideas about visibility in the opposite direction. Yet the notion of global state proves quite useful in the definition. ---Dan Difference between Multics and Ada: Multics was ten years *ahead* of its time.
gudeman@cs.arizona.edu (David Gudeman) (01/03/91)
In article <27823155.211e@petunia.CalPoly.EDU> John R. Dudeck writes:
]
]In the book, _Principles of Functional Programming_, by Glaser, Hankin,
]& Till, it is stated, "the notion of global state that may change
]arbitrarily at each step of the computation has proved to be both
]intuitively and mathematically intractable."
That is something of an exaggeration. The mathematics of global
states is almost trivial compared to the mathematics of recursive
functions.
It's hard to argue the "intuitive tractability" of global states, but
clearly the thousands (millions?) of working programs written under
the notion of a global state might be considered a counter-example to
the claim.
--
David Gudeman
gudeman@cs.arizona.edu
noao!arizona!gudemanburley@pogo.ai.mit.edu (Craig Burley) (01/03/91)
In article <27109:Jan301:33:4391@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: In article <27823155.211e@petunia.CalPoly.EDU> jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) writes: > In the book, _Principles of Functional Programming_, by Glaser, Hankin, > & Till, it is stated, "the notion of global state that may change > arbitrarily at each step of the computation has proved to be both > intuitively and mathematically intractable." That's a nice religion but it's simply not true. I am working on a formal, quite mathematical, definition for the semantics of my Q language. Q supports nonpreemptive threads and some amount of parallel processing. It supports data hiding even better than Ada---Piercarlo, if you're reading this, I stole your ideas about visibility in the opposite direction. Yet the notion of global state proves quite useful in the definition. Yes, I have a much easier time thinking about any global state if I imagine that all procedures have an "implicit" argument passed among them that contains the global state (an array of bytes representing all of memory, if necessary, perhaps even including I/O). In the object-oriented model, a similar approach can be taken -- think of global state as one huge object (if necessary -- multiple smaller objects when it is easily shown they don't interact) that all other objects know about, and treat all reads and writes to that state as messages to that object. Then any intuitions or mathematics (proofs) become easier, I think. The higher up one can abstract the global state (the more distinct one can show all of its elements to be, and the "closer" each element can be to getting "absorbed" by a few functions or objects), the easier the state was to deal with in the first place. Note this does not mean it is wise to start a new project using lots of global state -- I'm just pointing out that one can understand existing systems using this approach. Dan, does your Q language (or your formal definition) use this technique, or something similar, to deal with the global state you use in its definition? -- James Craig Burley, Software Craftsperson burley@ai.mit.edu
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (01/04/91)
Ever feel like you couldn't see the bugs for the program? The more program state/variables/definitions/procedures visible from one code segment, the easier it becomes for bugs to hide in that segment. That's the real reason that each segment should be as localized as possible. It's not for ``mathematical appropriateness'' or for proving that correct programs are, indeed, correct; it's for improving your chances of detecting the bugs in buggy programs. In article <BURLEY.91Jan3074344@pogo.ai.mit.edu> burley@pogo.ai.mit.edu (Craig Burley) writes: > think of global state as one huge object Nice. > Dan, does your Q language (or your formal definition) use this technique, or > something similar, to deal with the global state you use in its definition? The language per se has very little to do with the formal definition; I'm writing the latter mostly to make sure I know what I mean by the semantics of the former. Q doesn't give the programmer any way to refer to the entire program state. ---Dan
mac@eleazar.dartmouth.edu (Alex Colvin) (01/07/91)
In fact, global program states are such useful things that I often need more than one.
diamond@jit345.swstokyo.dec.com (Norman Diamond) (01/07/91)
In article <27823155.211e@petunia.CalPoly.EDU> jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) writes: >Is the issue of program state really the crux of the issue of program >tractability and of control of complexity in software engineering? It is a crux, not the only one. >It seems to me that the ability to localize program state is an essential >requirement, but I don't see why it should be necessary to eliminate it >altogether, as in functional programming. Functional programming has its place too. Yes it makes proofs easier and programming harder, and syntactic constructs have not been developed well enough to bridge these issues. -- Norman Diamond diamond@tkov50.enet.dec.com If this were the company's opinion, I wouldn't be allowed to post it.