[Haskell-beginners] Re: Applicability of FP unchanging things to real world changing things

Glurk streborg at hotmail.com
Tue Dec 15 02:53:31 EST 2009

I agree with the points some people have raised - as I said in the original 
post, I certainly like some of the things that FP gives me.

> Do they change state? Or do you see a new object with a different state than
> the previous object? Can you step into the same river twice?

I think a lot of people, looking at the real world, would answer, yes, it 
clearly IS the same book, now in a different state. And yes, I CAN step into 
the same river twice. This is how people see and think about the real world.

So, while I understand and like the benefits that thinking of things as 
mathematical concepts gives me, it seems to me that it does take your program 
further away from the real word, and thus can make it less understandable 
because of this.

There is a certain adavantage in having a close mapping from the real world to 
your program - if your program is meant to be dealing with real world things.

> As Master Apfelmus has written, what you see (or what you think you see, if
> that is different) is almost completely irrelevant to what is going on in 
> program in the computer. If you lend a book, the book doesn't change. The
> library doesn't change. What changes is a model of the library, which now
> indicates that a book is lent to someone, and the real question is how best 
> build that model of the library.

I agree with you, that yes, it's our model that we're really working with, not 
the real world, and that the question is how best to build the model.

However, in answering that question, as I said, I think that there are some 
advantages in there being a close relationship between the real world, and our 
model -  in terms of understandability, which, personally, I believe is one of 
the most important things in any system.

So, I'm not sure I agree that what we see in the real world is "almost 
completely irrelevant". If the mapping from real world to program is hard to 
understand, then it can make it harder to maintain. To make a farfetched 
example, if we model our book as an apple, and each time it is lent a bite 
gets taken out of it...... well..that's just completely ridiculous, right ?
It's ridiculous because what we see in the real world IS important to how we 
model. It certainly doesn't mean that we have to model things exactly as we 
see them - obviously, we drop things we think are irrelevant etc ...but, I 
think in generaly, it CAN make visualization and understanding easier, if our 
model has a certain similarity to the thing it is modelling !

So, I'm just thinking that in the real world, we typically do think of 
changing objects, so a model which also has this property, can help in 

Of course, if we train ourselves to think differently...then a model 
containing immutable objects might have more benefits than drawbacks - and I 
think that's what most FP supporters are claiming.

> At some point, you will ask, "What about these two Libraries floating 
> and realize that what you really need is a monad and ideally one specific to
> your Library (rather than the general IO monad). Then you will be 

I guess that brings up another point - that eventually we are drawn into 
monads, which to me seems a bit unfortunate, because it seems that it leads us 
back to imperative programming with mutable state...

As someone else suggested, perhaps FRP is an answer here..
..I must admit I don't understand much about that, I'll look into it a bit 
more ! 


More information about the Beginners mailing list