[Naming things] is not an OO exclusive but it is at the foundation of OO (naming things, relating them, and such).
Naming things is at the foundation of most human activities, making it less than useful to define OO.
[That OO decomposition and design reflects "how we perceive the world"] is not really how its pushed.
Sorry, but I disagree. It is. In this very HN thread we're replying to, for example.
Many people anthropomorphize their objects, which again is naturally human; again, objects are not for computers, they are for people.
Now you are trying too hard. No, it's unnatural to speak of "passing messages to objects". This isn't how people understand the real world (except for old ladies who speak to their plants, but they are not the target audience of Smalltalk or Objective-C), and in fact message passing is one of the most alien (and harder to understand) aspects of the OOP abstraction. So alien, in fact, that some OO languages do away with this terminology.
Naming things is at the foundation of most human activities, making it less than useful to define OO.
Yep, thinking in terms of "objects" is kind of broad and fundamental. It is preferable to the "OO is Java" definition that is often pushed.
Sorry, but I disagree. It is. In this very HN thread we're replying to, for example.
I was presenting what I thought was what really is seen as the benefits of OOP.
Now you are trying too hard. No, it's unnatural to speak of "passing messages to objects". This isn't how people understand the real world (except for old ladies who speak to their plants, but they are not the target audience of Smalltalk or Objective-C), and in fact message passing is one of the most alien (and harder to understand) aspects of the OOP abstraction. So alien, in fact, that some OO languages do away with this terminology.
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. 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).
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
Naming things is at the foundation of most human activities, making it less than useful to define OO.
Sorry, but I disagree. It is. In this very HN thread we're replying to, for example.
Now you are trying too hard. No, it's unnatural to speak of "passing messages to objects". This isn't how people understand the real world (except for old ladies who speak to their plants, but they are not the target audience of Smalltalk or Objective-C), and in fact message passing is one of the most alien (and harder to understand) aspects of the OOP abstraction. So alien, in fact, that some OO languages do away with this terminology.
Yep, thinking in terms of "objects" is kind of broad and fundamental. It is preferable to the "OO is Java" definition that is often pushed.
I was presenting what I thought was what really is seen as the benefits of OOP.
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. 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).
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.