Quite a good explantion - the idea of having immutable data is a really strange one to wrap your head around when you have been doing OO for most of your career.
I'm just getting into clisp (I read somewhere that it is inevitable that everyone on HN will eventually try lisp when they have been around long enough) at the moment, and would like to try my hand at some Haskell later as well, and one of the hardest things to do is to think of data in FP terms.
You think it's weird now, wait until you start building infinite lists or writing recursive functions with no terminating case as part of your everyday routine in Haskell :)
Yes, but it's not being modified in place, so you can selectively re-use it. Immutability is the big thing.
In FP, you typically "change" a data structure by creating a shallow copy of it with a few parts replaced, but the rest just pointing back to the original - nothing's changed directly, and when data is no longer used, it's eventually garbage collected. (Typically, with a generational and/or copying collector, whose costs are proportional to surviving data.)
This works better with trees and lists than it does arrays and hash tables, because changes to those usually require adjusting as a whole. To add to the head of a linked list, you can just create a new cell of [new value, head of old list], which is very cheap. (Adding to the tail can be done with e.g. a deque). At the same time, anything that adds to the list won't interfere with other code that is holding a reference to the same list, or even accessing it concurrently.
Probably the best way to learn about purely functional data structures is from the book of the same name by Chris Okasaki.
I'm just getting into clisp (I read somewhere that it is inevitable that everyone on HN will eventually try lisp when they have been around long enough) at the moment, and would like to try my hand at some Haskell later as well, and one of the hardest things to do is to think of data in FP terms.