Anthropomorphisms are as old as Aesop; heck before we had much formal science, it was are only way of understanding things (reading Plato and Aristotle). Message passing is just communicating with something, you might not ever think "we have to tell that object to update itself" but plenty of people do.
I understand what you're saying, I just disagree with it. No-one I know thinks in terms of "I have to send the teapot the message to pour tea"; it's just an unnatural way of thinking. Our old lady from the example may think of her lovely Chinese teapot as a "she", might even name it, but she still won't think in terms of sending messages to pour tea. People don't think that way. And that's alright: OOP is a formalism (like Math, only probably less formal), not a "natural" description of the world.
Note I'm not really a big fan of message passing, and it is hardly something exclusive to OO (my colleagues are very much into RPC without an object in sight).
Message passing was defined by the inventor of OOP as its defining feature. Of course, Java, C++ et. al. then subverted this, but that's an entirely different debate.
----
To make this debate more constructive: I think OOP is valuable as a way to do modularization. Modularization is a worthy goal, but OOP is just one way to do it. Not the best way, but the one most programmers are familiar with, regrettably to the exclusion of other approaches.
I disagree with Kay on his assessment of OO, I disagree that he's even the inventor of it (though he coined the term, word out to the Scandinavians and even Sutherland).
I would claim that OOP is not about modularization at all; it is a way of thinking meant to help humans solve problems with a computer. It's a crutch, it is easy to apply, and has lots limitations. FP (thinking in terms of anonymous values vs. named objects) is an alternative, though more experienced programmers often use both ways of thinking where best appropriate (which is why you'll see OOP entity interfaces in languages like Clojure, and lots of immutable structs in C#). Neither can claim a decisive benefit in modularity or code reuse; you have to work extra hard for those.
Comments
I understand what you're saying, I just disagree with it. No-one I know thinks in terms of "I have to send the teapot the message to pour tea"; it's just an unnatural way of thinking. Our old lady from the example may think of her lovely Chinese teapot as a "she", might even name it, but she still won't think in terms of sending messages to pour tea. People don't think that way. And that's alright: OOP is a formalism (like Math, only probably less formal), not a "natural" description of the world.
Message passing was defined by the inventor of OOP as its defining feature. Of course, Java, C++ et. al. then subverted this, but that's an entirely different debate.
----
To make this debate more constructive: I think OOP is valuable as a way to do modularization. Modularization is a worthy goal, but OOP is just one way to do it. Not the best way, but the one most programmers are familiar with, regrettably to the exclusion of other approaches.
I disagree with Kay on his assessment of OO, I disagree that he's even the inventor of it (though he coined the term, word out to the Scandinavians and even Sutherland).
I would claim that OOP is not about modularization at all; it is a way of thinking meant to help humans solve problems with a computer. It's a crutch, it is easy to apply, and has lots limitations. FP (thinking in terms of anonymous values vs. named objects) is an alternative, though more experienced programmers often use both ways of thinking where best appropriate (which is why you'll see OOP entity interfaces in languages like Clojure, and lots of immutable structs in C#). Neither can claim a decisive benefit in modularity or code reuse; you have to work extra hard for those.
We can definitely agree to disagree on this.