I come from an OO background, but have recently started to see the light and think that functional programming has a lot to offer in real world, general software development - not just some small specific niche. Having the OO background certainly has limited the way I view software development, and I guess in learning something new, I have a tendency to compare it with what I do know, looking for similarities and differences. So, perhaps that's why I am having difficulty in seeing how some functional programming ideas apply. What's got me a little puzzled at the moment is non mutable data. On the one hand, I think it's great that I can mostly forget about errors caused by my variables having unexpected values, and that I can reason about my program much more easily... 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. 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 ? Is there where we part company with non mutability and venture into the monads where we do have side effects ? Any thoughts appreciated ! :) Thanks !