Re: is state bad?

amyc@well.sf.ca.us (Amy Caplan) writes:


>I think I have encountered a viewpoint that local state is bad,
>presumably because it makes programs more difficult to understand
>and debug. (e.g. violating the notion of "referential transparency").
>
>This would seem to be in conflict with the "object oriented" trend,
>which often encourages local state.




State is a favourite hobby-horse of mine. So is OO-bashing. :-)


In terms of the development, the rise of structured programming eliminated
one form of state from the programmer's control. The context of a piece of
computation was to some extent hidden by the use of procedures and
functions, and by avoiding explicit goto statements. The use of structured
programming and procedural abstraction works well - it enabled much larger
programs to be developed at reasonable cost and bought a stay of execution
for large software systems for well over 10 years.


The use of object oriented techniques also helps mask some state by making
it only indirectly acessable. However it as Amy suggests encourages making
the state local, rather than hiding it from the programmer altogether. I
expect it to be relatively much less significant in managing the
complexity of large programs. The real problem from my experience is the
difficulty of maintaining the proper invariants on data-structures during
a series of updates. When the state is implicit (as it is in imperative
languages including the typical object oriented languages), it is very
easy to forget some aspect of the interaction between updates.


In the pure declarative languages (such as Haskell, Goedel and Mercury),
any state must be made explicit by passing the relevant pieces of state
from one function or predicate to another. By needing to pass the pieces
of state explicitly, the programmer is less likely to overlook
interactions. Also, in many cases the programmer will use state-free
alternative algorithms simply because they are more convenient in
declarative languages (for instance recursively computing something from
the elements of a list rather than iterating over the list).


Traditionally, the declarative languages have been too inefficient to be
serious condenders in many application areas, but new languages and
compilers are emerging that produce executable programs with comparable
efficiency to current imperative languages. There is no reason to expect
that these new compilers cannot continue to improve as more sophisticated
high level (source level) optimisations are implemented.


An interesting development will be parallel logic languages with high
performance. In these languages there are programming techniques that
correspond more or less directly to objects and message passing. It
occurs to me that it is possible that the problem of managing state is at
some fundemental level a problem of programming technique rather than a
problem of language design. While it is true that one language may
encourage good technique better than another, if the programmer wants to
use state in risky ways, then he or she will always be able to find a way.


Any comments, flames, or opinions welcome.


Thomas
--
Thomas Conway conway@cs.mu.oz.au
--

Return to the comp.compilers page.
Search the comp.compilers archives again.