Why are objects so unintuitive?

"Yet even with the amount of programs being written and problems about objects being solved, rather than converging on a complete representation of real-world objects, objects in programs seem to diverge, where an object from one project is different from an object from another project and is typically different from how a normal person thinks about the real world object."<p>The problem is not with object-oriented programming. It is a problem of our minds, of philosophy, of language.<p>An apple is an object. Our minds cannot know everything about an apple: the amount of information is too vast (the number and position of cells, different varieties, how to farm them, the quality of this particular apple, how it tastes to snakes, etc.).<p>So our minds create mental models of objects by assembling only a fraction of the information needed. The information that we use to construct our mental model is not random: it is goal-driven. I don't know much about apples except which ones I like and how to spot rotten ones. My mental models support my goal of eating tasty apples. If I were an apple farmer or even a cook then my mental model would need to be richer.<p>People will have many different mental models of a "real world object" depending on what their goals are with that object. So the problem of not converging on a "complete" representation of an object is not a limitation of object-oriented programming, it's an artifact of how our minds deal with the overwhelming vastness of the information around us.

This apparent mismatch has mostly to do with the common use of oo, rather than oo itself. Joe Armstrong, creator of Erlang, is famous for quoting Alan Kay (who invented OO) when he wrote that the big idea behind smalltalk is not classes or objects, but messages (Joe Armstrong recently mentioned this at 4:30 of his most recent Qcon presentation: <a href="http://www.infoq.com/presentations/Message-Passing-Concurrency" rel="nofollow">http://www.infoq.com/presentations/Message-Passing-Concurren...</a>)<p>Jim Coplien and Trygve Reenskaug discussed this apparent mismatch on the article: <i>The DCI Architecture: A New Vision of Object-Oriented Programming</i> (on <a href="http://www.artima.com/articles/dci_vision.html" rel="nofollow">http://www.artima.com/articles/dci_vision.html</a>).<p>Jim also recently gave a presentation on the subject: <a href="http://www.infoq.com/interviews/coplien-dci-architecture" rel="nofollow">http://www.infoq.com/interviews/coplien-dci-architecture</a>.

Because most programs aren't simulators, and there often isn't a natural way to map the concepts involved in an application to that of the real world. When you move beyond the garbage examples they give in computer science 101 ("RaceCar extends Car") you realize objects still have their place, just not in the way the professors taught you.

As others have said; objects in programming languages do not map well to objects in the real world because a. the real world is vastly more complicated than any constructed abstraction, and b. our minds permit vagueness whereas computers do not.<p>It is not the case, anyway, that say nouns map to real-world objects for example. There are infinitely many variations and intricacies in the way we humans interpret nouns, many of which are entirely context-based. That is another issue - PLs do not have a sense of context the same way we humans do (which is probably a good thing as I'd rather a PL be less vague than a highly context-sensitive conversation with a friend.)<p>For an indication of the depth of complexity of natural language and the philosophical difficulties therein, Ludwig Wittgenstein's Philosophical Investigations is a good place to look - <a href="http://en.wikipedia.org/wiki/Philosophical_investigations" rel="nofollow">http://en.wikipedia.org/wiki/Philosophical_investigations</a>.<p>I do think there is a deeper issue with objects in that the environment in which they are constructed often fails to permit the kind of complicated interrelation that the concept of the object should actually have, i.e. there is not enough freedom to compose and combine objects in a way entirely cohesive with the way you think of the object. However that has less to do with the relationship between natural language and programming and more to do with the limitations of oop itself.

Often, you are only interested in a "view" of this object. A subset of the total methods and data of the real world object. For example, an inventory app may only car about the MSRP, dealer's cost, etc and not necessarily implementing the functions of a real car ( horn.honk() door.IsOpened).<p>Now, software inside the car may well want to abstract the horn.honk() function for use. (maybe, i'm doubting it's that clean in implementation).<p>Anyway, not ever app cares about ever aspect of every real world object. Hence lack of re-usability. Even 2 LOB (line of business) app may have different views to the same object. For instance, a telecom circuit. One app is concerned with the physical layout/design, where it runs, what equipment, what locations, what size (bandwidth) etc, etc. While another app may account for this circuit, figuring cost and revenue. Both may share data, but much more likely at a database level than actually pulling objects out of one, straight into another. I've just not seen that level of re-use in biz apps. String is used all over the place, but a highly specialized class for telecom accounting? Probably not. However, these apps probably share customer information because customer contact info is useful for billing and trouble shooting connectivity issues.<p>So object re-use works great as a software vendor like Sun(oracle) or Microsoft. Java and .Net have some objects that see major re-use. Network, strings, web, drawing, etc. Very common, very easy to re-use. But LOB apps just don't have that re-usability. If they did, why would they need to hire you to work on them? They could just pull it out of the box.

Object oriented programming grew out of simulation of real world objects.<p>Turns out, good OO design requires objects to NOT be like real world objects, at least in some parts, and the OO field has moved past it. However the terminology is still all bound up in simulation type objects, and people are often confused by examples used in schools and books about animals and dogs and barking.

Like many other discussions about objects / OO, some of the confusion comes from having several (often contradictory) definitions of what constitutes an object. Is it an agent that responds to a given set of messages? Is it an instance of a class? What about prototypes? Is inheritance fundamental? What about CLOS? Etc.

The concept of the 'uncanny valley' may be relevant here. (For those unfamiliar: <a href="http://en.wikipedia.org/wiki/Uncanny_valley" rel="nofollow">http://en.wikipedia.org/wiki/Uncanny_valley</a>)<p>Here's my unexamined hypothesis: Objects in programming are unintuitive because they aspire to resemble real-world objects, but inevitably fall short. When you're thinking about some abstract programming feature, your brain knows it's meant to be thinking abstractly. But when you think about an object, your brain can slip into an uneasy DMZ between thinking about abstractions and thinking about real-world objects.<p>In other words, the problem isn't that objects aren't similar enough to real-world objects—it's that they're <i>too similar</i> without being identical.

Often it's revealing to ask the reverse question. In this case<p>"Why is natural language so intuitive?"

probably because reality is a lot more complex than a computer program.<p>most objects in the real world are just clumps of atoms and don't respond to messages.<p>you can take a loaf of bread and slice it into 12 separate objects. do that to a C++ object and you get twelve clumps of 1s and 0s that are completely meaningless.<p>objects are just attempting to model the world. the model is not the world, any more than a painting or photograph or a story is a real world experience. all are just tools that let you think about the real thing.

The comments on the article are more insightful and correct than the article itself.