Re: Functional Programming in the Larger or Functional Oriented Software Engineering

On Thu, Mar 29, 2007 at 09:45:45AM -0700, Joe Marshall wrote:
> 
> >On Thu, Mar 29, 2007 at 08:29:23AM +0200, Peter Van Roy wrote:
> It's actually not a good idea to completely get rid of state, because using
> state can give programs with good modularity properties, which is not
> possible without state (see, e.g., the explanation in the CTM book).  But
> you're right, state should definitely not be the default.
> 
> On 3/29/07, Robbert Haarman <[email protected]> wrote:
> >
> >Actually, I don't believe it's possible to do anything useful without
> >state.
> 
> I'm not a radical `Enemy of State' by any means.  When I first learned
> how to program, I was told that `state is bad'.  Of course I didn't
> believe it, but I went with the program and avoided using state when
> faced with the choice of using it or not.  With more and more
> practice, I found I could write a lot of complex programs without
> using any state at all.  I have written a couple of compilers that
> use no mutation at all and a database that is pretty close to
> being completely state-free.

I'm sure you have, and I'm sure it was a good idea to write the programs 
that way, but my point is that, at the end of the day, you will want to 
modify state. E.g., in case of your compiler, you will want to output 
the result of the compilation. In case of your database, you will want 
to commit completed transactions to stable storage. In general, you will 
want the state of the world to be updated by the result of your 
computation (which may itself be stateless).

> On the other hand, I don't think `world-passing-style' (monads)
> are the solution, either, so I'm not quite ready to jump on
> the absolutist platform.

As far as I understand monads, they are impose a barrier between 
referentially transparent code and code that performs destructive 
operations. Code not inside a monad that performs destructive operations 
can be assumed to be referentially transparent, aiding analysis 
(understanding, optimization). I think clear separation of destructive 
and non-destructive code is a Good Thing, as is defaulting to 
non-destructive code and requiring the programmer to make some effort to 
perform destructive operations. So, assuming I got all of this right, 
monads are just what the doctor ordered.

Regards,

Bob

-- 
I live my life according to a set of immutable, ever-fixed, unchanging
principles...most of the time.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGDiRLfb9wcmD+WN4RAjrpAKDUqYxjSHUPe8l5dots+Fb48l7UawCfWkoz
3e7tN8u14k0y9Ogh6z9P/jk=
=SQlo
-----END PGP SIGNATURE-----