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

On 3/31/07, Robbert Haarman <[email protected]> wrote:
>
> 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).

This kind of state seems more benign than the kind where
you are mutating data structures as the computation proceeds.

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

I agree that separating things is good, but monads have several practical
drawbacks.  They are tricky to understand, they don't compose, and they
use a lot of resources.  I'm not convinced that the advantages outweigh the
disadvantages if there is a choice.


-- 
~jrm