Sorry, no. It is calling data mutable that is the confusion.
Try this exercise:
Identify something you consider a datum. Write it down. Note that it has more than one part. Now imagine it 'changing' and write that datum down. Now, identify the 'it' that (you would say) changed. Note that the 'it' part is the same in the 2 datum. Let's call this 'it' part the identity. Now look at the part that is different. For discussion's sake let's say that part was 42 in the first case and 99 in the second. Did 42 change into 99, or was it replaced by it? Let's call 42 and 99 values. You'll not be able to describe something that 'changed', that incorporates both the identity and value, that doesn't involve some memory/disk/system that had a (just one!) 'place' for storing information about 'it', and it is that place that has had it's contents replaced/changed, not the datum/fact.
Did Obama becoming president change the fact that Bush had been president? No. Could you make an information system that forgot Bush was president? Sure, but that's your fault, not a characteristic of data.
Finally, check out this 30 year old paper that contains this interesting section: UPDATE IN PLACE: A poison apple?
As long as we continue to use lax language like mutable/updateable data we will be without the tools to describe, think about, and build better systems that independently manipulate identity, value and place, and correctly handle time.
I'm sorry. I don't understand the point of the exercise.
First, what kind of data are you talking about? Are you talking about data value? Data record? Data object with identity?
Second, are you saying database records being mutable cannot model Bush was a president once Obama has become president?
I don't know the reason for the aversion to mutable data record/object. Both mutable and immutable data record/objects have their places in modeling real world objects.
Can you give some specific examples of bugs stemming from mismanagement of mutable state? Some examples on bugs resulted from the failure to coordinate state changes or poorly-designed state changes? And how the immutable data solve the problems?
There are literally too many to list. But if I just had to pick some recent ones:
* A dropdown on a web form that displays a different value than is returned (failure to coordinate the displayed value and the "actual" value)
* Logins remain locked after resetting a password (failure to change a value from "locked" to "not locked", instead of "is the user locked?" being a function of history)
* If you navigate to a business object from a list, and perform an action (via HTTP POST) on that object, you can accidentally perform the same action on other objects from that list through refreshing or clicking multiple times (since the "current" object is in the session state)
* Bugs that only happen when you navigate to a page from a certain other page (because the destination page depends on certain session state that was not set, instead of being a simple function of URL parameters)
Not that I don't believe you. It's just that I want to learn from specific examples on what kind of problems people encounter when dealing with mutable data and how would immutable data solve the problems.
So how would immutable data solve the above problems? Thanks.
Try this exercise:
Identify something you consider a datum. Write it down. Note that it has more than one part. Now imagine it 'changing' and write that datum down. Now, identify the 'it' that (you would say) changed. Note that the 'it' part is the same in the 2 datum. Let's call this 'it' part the identity. Now look at the part that is different. For discussion's sake let's say that part was 42 in the first case and 99 in the second. Did 42 change into 99, or was it replaced by it? Let's call 42 and 99 values. You'll not be able to describe something that 'changed', that incorporates both the identity and value, that doesn't involve some memory/disk/system that had a (just one!) 'place' for storing information about 'it', and it is that place that has had it's contents replaced/changed, not the datum/fact.
Did Obama becoming president change the fact that Bush had been president? No. Could you make an information system that forgot Bush was president? Sure, but that's your fault, not a characteristic of data.
Finally, check out this 30 year old paper that contains this interesting section: UPDATE IN PLACE: A poison apple?
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.108....
As long as we continue to use lax language like mutable/updateable data we will be without the tools to describe, think about, and build better systems that independently manipulate identity, value and place, and correctly handle time.