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

[Tommy M. McGuire]

Glurk wrote:
> However, on the other hand, I wonder how it ties in with real world systems 
> that do in fact do deal with objects that change state.

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?

> For example, if I was building a library system - I might have book objects, 
> and if a book gets borrowed, there remains the same book object, but it now 
> just has a different state - from "on shelf" say, to "borrowed".
> 
> Now, in Haskell, I might have a function to lend a book :-
> 
> lend book1
> 
> and this is going to return a new book, with the appropriate status change..
> ..but what of the old book ? I don't want 2 book objects floating around..
> ...to my way of thinking, it's really not a new book, it really is a change of 
> state.
> 
> How do people see this kind of situation ?
> Is it just the way of looking at it... ?
> Do I just accept that I toss out my old library object, and have a new one, 
> which happens to be the same as the old one, except for the "new" book which 
> is now borrowed ?
> 
> Do I really need to get over thinking of objects in the first place, even 
> though it's what I see exist in the real world ?

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.

Most object oriented languages are inherently procedural; this is equivalent
to writing all of your code in the IO monad. Haskell gives you more options
than that, including writing pure functional code with the type

lend :: Book -> Library -> Library

which has all sorts of neat properties that help you build the model without
falling into some of the potholes that go along with procedural programming.

> Is there where we part company with non mutability and venture into the monads 
> where we do have side effects ?

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.


-- 
Tommy "Gotta cut down on the cold meds" McGuire
mcguire at crsr.net