Or as Gilad Bracha summarized (in reference to Cook's article): "The notion of an interface is what truly characterizes objects - not classes, not inheritance, not mutable state."
God, this is again one of those CS papers that is written as if it's trying to be as inscrutable as possible.
Can't the author lead in by giving a simple example of both abstract data types and objects (as he understands the terms), in a well-known programming language?
It's actually a pretty scrutable paper. Most of the examples are in ML (or an ML-inspired notation). They are concise and clear in their presentation if you spend a moment scrutinizing them if you happen to be unfamiliar with the ML-family of languages. It's not like he used MUMPS for his example code. And his prose is reasonable, he avoids excessive notation and jargon beyond what a computer scientist or programmer with modest experience in a functional and an OO language ought to be able to work out. It might be inscrutable to a total novice or outsider, but that's probably not the target audience.
The core of the distinction is well-summarized with this paragraph from page 7:
> This difference is fundamental: abstract data types have a private, protected representation type that prohibits tampering or extension. Objects have behavioral interfaces which allow definition of new implementations at any time.
The other big difference is brought up on page 10 with respect to the "Expression Problem". It is easier to add operations to ADTs than representations, and easier to add representations with objects than operations. Though this pretty clearly relates back to the quote I provided. (And as he notes this has been solved in various ways in various languages and systems over the years; he's discussing this more from a "pure" ADT/object perspective.)
I don't think he can. As he says towards the end of the introduction: "One source of unease is that the fundamental distinctions are obscured, but not eliminated, in real programming languages."
https://gbracha.blogspot.com/2022/06/the-prospect-of-executi...
(the "not mutable state" bit is what makes a function an object for me but that's an ancient debate: http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/m...)