Is-a and has-a, and more to the point, naming things, is just an outgrowth of our natural linguistic capabilities. The alternative is anonymous immutable values with structural comparisons (aka functional programming), which we've only been studing as math for a couple of thousand years or so (vs. Around 100k years for language).
I don't know if the alternative is functional programming or structural comparisons, and I wasn't arguing that in this particular case. I agree about naming things, but I don't consider it an OO exclusive.
What I'm saying is that there are a couple of assertions, more or less accepted in the industry, that may be flawed or simply false, and that may have led to the current mess of software design:
1- That OO decomposition and design reflects "how we perceive the world".
2- That if there is merit to this notion that we naturally decompose/understand the world in terms of objects, has-a and is-a, that this maps to the set of formalisms we usually call OO Design & Programming. For example, it's obvious to me "message passing" is a (sometimes useful) abstraction completely alien to how we perceive the world -- nobody thinks in terms of sending messages to the objects. A message is something you send to another sentient being, preferably a person.
> I agree about naming things, but I don't consider it an OO exclusive.
It is not an OO exclusive but it is at the foundation of OO (naming things, relating them, and such). Math (outside of maybe graph theory) is the exact opposite (names lie about fundamental truth, let's work with truth); that is the direction that pure functional programming really takes (many reduce it to immutability, but that is just a consequence of not having identity and aliases).
> 1- That OO decomposition and design reflects "how we perceive the world".
That is not really how its pushed. It is more about how we "talk" about the world. After all, humans are writing the programs, probably together, talking to stake holders and all. OO is not the best way to talk to the computer, but it might be the best way to talk to humans about programs until we can evolve into more Vulcan like creatures.
Also, are evolved capability for language has greatly influenced how we think and solve problems. People find it easy to talk about things, ascribe names to them, and arbitrarily relate them to other things. This really gets in the way of learning math for most people (names and ascribed relations are informal, they can lie), but it is very accessible to deal with the computer world like you would the physical world (even if it is often technically wrong).
> For example, it's obvious to me "message passing" is a (sometimes useful) abstraction completely alien to how we perceive the world -- nobody thinks in terms of sending messages to the objects. A message is something you send to another sentient being, preferably a person.
Many people anthropomorphize their objects, which again is naturally human; again, objects are not for computers, they are for people.
> [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.
