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

> > Joe Marshall wrote:
>
> > >Of course it is better to be rid of the state altogether, but that
> > >requires learning a new paradigm.

> 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. That is not the same as saying that avoiding state when practical
> is not a good idea, but eventually, state will have to be modified.

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've also debugged a lot of complex programs.  *Many* *many* bugs
are the direct result of someone modifying something that someone
else didn't expect to be modified.  Large complex systems spend
a huge amount of time copying structure to protect themselves from
accidental mutation.  Look at a large system coded in Python and
see how much time it spends in deep-copy.

Given how many bugs and kludges I've seen to work around bugs
in a stateful system, and given that I've seen a number of large
complex systems that are state-free (and simply *cannot* exhibit
state-associated bugs), I've started to rethink this idea of `state
is bad'.  I'm coming to the conclusion that state is *far* worse
than most people think, and even the rabid Enemies of State
are underestimating it.

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.

> > >What is really nasty about the current OOP trend is that it actively
> > >encourages the use of state.  The standard container libraries that
> > >come with these languages have tons of methods for modifying, adding,
> > >deleting, iterating over things in a stateful way,
>
> Which is a Good Thing; it's good to be able to express that, although
> the color has been changed, it's still the same car.

Well, if you want to allow someone to paint their car, yes.

But when you go to the dealer to buy a new car, and you find that they don't
have a red one in stock, you probably don't want them to repaint one of the
ones they *do* have.  And you *certainly* don't expect the automobile
manufacturer to customize your car by duplicating the showroom car to
the last detail, then scraping off the duplicated paint and repainting it red.

Now it may be the height of wastefulness to tell people that if they
if they want to change the color of their car that painting is not an
option --- they must purchase a brand new car of the correct color,
but if you have the resources (if cars are cheap or free), this really
isn't such a bad option.



-- 
~jrm