I disagree with that and that particular paper. We must think of objects from a design perspective, not a technical one, and the one thing that distinguishes objects is their ability to be "things" rather than just constructs.
42 is not an object because the value can reproduced easily. John Smith, on the other hand, is not just a value, but has a name and an identity, is not exactly the same person everyday, and so on. 42 can be used in equational reasoning (it never lies) while John Smith cannot. John Smith, on the other hand, can be attributed with semi-autonomous behavior while such notion isn't meaningful for 42.
> We must think of objects from a design perspective, not a technical one
Why? Why should objects exclusively get this distinction when every other programming language paradigm is analyzed technically?
> 42 is not an object because the value can reproduced easily.
So?
What's the point of making "object" synonymous with "identity" when we already have the term "identity" to designate the relevant property?
Survey a bunch of programmers and ask if they agree with the phrase "objects respond to messages, and the only way to interact with an object is to send it messages". I'd wager a majority would agree with this statement. Which means procedural abstraction/encapsulation, wherein no details about object internals can leak to clients, is the only meaningful property of objects. 42 can then take on many representations, as long as they all respond to the same messages.
> Why? Why should objects exclusively get this distinction when every other programming language paradigm is analyzed technically?
Who is analyzing? I definitely don't analyze other paradigms technically. You should know me better than that. I'd rather all paradigms be analyzed based on how they are used to write programs and how they influence program designs. The technical details are just details.
> What's the point of making "object" synonymous with "identity" when we already have the term "identity" to designate the relevant property?
Again, it is how you design your programs: are you relying heavily on equational reasoning, or have you divided things into a bunch of nouns with behavior.
> "objects respond to messages, and the only way to interact with an object is to send it messages".
They might indeed, but it is a vacuous statement to begin with. It is extremely sad how little design is considered in programming languages. That an entire paradigm could be boiled down to such a true but useless statement.
> I definitely don't analyze other paradigms technically. You should know me better than that. I'd rather all paradigms be analyzed based on how they are used to write programs and how they influence program designs. The technical details are just details.
The technical details define how programs are structured. I don't see how you can separate these questions if that's what you mean by "design".
> Again, it is how you design your programs: are you relying heavily on equational reasoning, or have you divided things into a bunch of nouns with behavior.
Sure, but this doesn't preclude immutable objects from being used in subprograms that don't depend on state transitions. For instance, object factories may or may not be immutable, but if they are, they're suddenly not objects anymore? That distinction seems pointless.
> They might indeed, but it is a vacuous statement to begin with.
I agree that many people might take virtually anything to be a message, but when you try to specify with technical precision what that phrase actually entails, you get meaningful constraints, and I think Cook did a pretty good job distilling those properties.
For instance, "the only way to interact with an object is to send messages" means that no information can be revealed than what the object volunteers, ie. encapsulation, and this voluntary disclosure can't be captured statically to enforce stronger properties as with ADTs.
Design is like what does my program look like when I use X vs. what does it look like when I use Y? What are the implications of those two choices? I see objects and functions are pure design abstractions: you can easily emulate one or the other in a language that doesn't provide them as first class constructs, and even when they are provided as first class constructs, you can always use them in ways that are poor for the designs they support.
That "objects communicate via messages" leads to absurdities like numbers being considered as objects. It is completely blind to their benefits and drawbacks as anthropomorphic entities.
> That "objects communicate via messages" leads to absurdities like numbers being considered as objects.
It's only absurd if you're implicitly ascribing properties to objects that haven't been explicitly justified.
It seems perfectly reasonable to me that numbers would be objects, because numbers have a multitude of representations, all of which we'd like to be interchangeable. For instance, machine registers vs. arbitrary precision numbers. With ADTs, we'd have to explicitly define overloads for addition that handle the various permutations of parameters for addition of various number types, but a Cook-like object language wouldn't need this at all. Any representation of a number would be interoperable with any other implementation, automatically. That's neither vacuous or absurd, and these properties follow directly from taking that phrase describing objects to its logical conclusion.
When we come down to this, it is clear we just have very different of what objects are or are supposed to be. Interoperability (polymorphism) is at the center of the definition that you are using, and it is nowhere near as important in my definition of object, where polymorphism is possible with values and not related to their objecthood (it is a technical detail in how values can be made polymorphic).
We are talking past each other because we don't possess compatible meanings of the word object.
I don't think we're talking past each other, as I think we both understand the differences in each of our definitions, ie. I understand you think identity is central but I disagree, and you understand that I think procedural abstraction is central, but you disagree.
Where we differ is which definition ought to deserve the label "object", in the pure sense the way we have a definition for "function".
Even function has a definition in the philosophical sense unrelated to even the technical details of the lambda calculus. Especially when the function is pure and/or continuous, these are really useful distinctions in a design vs. using a bare bones definition that talks about a function being a pointer to some code.
> Even function has a definition in the philosophical sense unrelated to even the technical details of the lambda calculus.
Agreed, "function" has many concrete definitions, but arguably, there is some essence of what it means to be a function that we see reflected in each instance, and so virtually all of them are interconvertible in some real sense.
For "object", I see this essence as procedural abstraction. Every discussion of objects features access to data mediated by arbitrary code, which is how they implement behaviour. Object factories and numerical abstractions (fixed, rings, arbitrary precision, etc.) simply don't fit into your narrative of objects, so defining objects as requiring identity is immediately refuted in my mind.
Certainly you could argue that your approach to objects is better for software construction, but I don't think that means other approaches are no longer object-oriented, in the way that we can say that C permits you to violate the essence of functions.
I see objects as being completely unrelated to procedural abstraction, especially in its purest anthropomorphic form where objects have their own independent actuators and sensors (e.g. As in Kodu without any procedures at all, but also heavily used in etoys, scratch and of course Simula). In that case, they are just little entities (with identities of course) doing their own thing and communicating only through their environment.
It sounds like you're using "object" and "not an object" in the same way I would use "entity" and "value". I think this is Java terminology that gets used in C# sometimes too, I'm mostly thinking about NHibernate.
A value like 42 is fixed throughout time, it is always 42, and any 42 is indistinguishable from any other 42.
An entity on the other hand has an identity over time, so John Smith is always John Smith, even if he gets married and changes his name to John Brown.
Obviously it is confusing having different groups using the same words with different meanings, but that's just the way language works.
Language is always overloaded in the object-oriented sense. In the functional programming world, definitions are defined much more precisely, but then words have much less flexibility in how they can be used.
42 is not an object because the value can reproduced easily. John Smith, on the other hand, is not just a value, but has a name and an identity, is not exactly the same person everyday, and so on. 42 can be used in equational reasoning (it never lies) while John Smith cannot. John Smith, on the other hand, can be attributed with semi-autonomous behavior while such notion isn't meaningful for 42.