Objects, as seen from the outside, are entities with an identity and with behavior (hopefully associated with some interface contract). In addition, state may be part of the observable behavior of objects (and of their internal implementation). Data has no identity and no behavior, it is an immutable value. (Mutable data structures are actually objects.) Of course, you can realize objects in terms of data (e.g. machine code is data, and state is commonly represented by data), and conversely you can create objects that behave like data (like an immutable data structure), that is, realize data in terms of objects. That doesn’t mean that objects are data or vice versa.
The “identity” and “behavior” encapsulated in an “object” is just more data to be interpreted in the right context. x86-encoded behavior of an object will all be gibberish to an ARM CPU. Or 64-bit code to a 32-bit CPU. You can add more data to say how the other data should be interpreted, but then you need even more data somewhere to state what the set of addressable interpreters is, which needs an interpreter as well. Data upon data upon data…
Agreed, but I prefer to think of immutable data as a message because, in line with Alan Kay's thinking, data is always going to be interpreted by something (even if that something is a person).
I think Alan Kay is saying that messages aren't good enough, and so he favors objects over data, because objects are more than data, they are also the interpreter of the data.
My understanding is that he'd favor something where the code to interpret the message is also serialized and stored/retrieved and passed around, which is how I think Smalltalk works.
Thus Alan Kay favors objects, which are not actually data, but they are data+interpreter bundled together. Where as Rich Hickey favors data on its own, and facilities to represent and model data alone, independently of a given interpreter, and then he favors having various external things apply their own interpretation of the data.
