Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.object
Subject: Re: Global program state.
Message-ID: <2041:Jan320:07:2091@kramden.acf.nyu.edu>
Date: 3 Jan 91 20:07:20 GMT
References: <8mq8u2w162w@eosvcr.wimsey.bc.ca>
Organization: IR
Lines: 34

In article <8mq8u2w162w@eosvcr.wimsey.bc.ca> aew@eosvcr.wimsey.bc.ca (Alan Walford) writes:
> Show the following to a mathmatician:
>    x = 2
>    x = 3
> and he/she will say one of the statements is untrue. Show it to a programmer
> and he/she would say x gets assigned 2 and then 3; x's final value is 3.

A mathematician who knows what's going on might prefer to think about it
like this:

  ``x = 2''(state) = (state where x holds the value 2)
  ``x = 3''(state) = (state where x holds the value 3)
  ``x = 3''(``x = 2''(state)) = (state where x holds the value 3)
  ``x = 2; x = 3''(state) = ``x = 3''(``x = 2''(state))

Yes, folks, ``x = 3'' is a function which acts upon a (global) program
state to produce a new state. ``x = 2; x = 3'' is the composition of
those functions. And so on. A programmer might think about it this way
too.

> Yes, this is a silly and trivial example but I think it does fundamentally
> show that allowing state in a program makes proving correctness all that
> more difficult.

Yes, that is a silly and trivial example. What do the supposed mindsets
of mathematicians and programmers have to do with whether functional
programming encourages fewer bugs than object-oriented programming?

> I think the only successful work in program correctness
> proving has be done in functional (ie. stateless) programming.

This is a nice religion too, but it's simply not true.

---Dan