[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
your
> 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
to
> 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
understanding.
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
around?"
> 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
enlightened.
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 !
Glurk
More information about the Beginners
mailing list