Lambda the Ultimate

For example, what are the difficulties, if there are any, with the everything-is-an-object premise? When do object hierarchies exist and how do you find one or choose one of several? In what ways is an object-oriented design robust to changing specifications and imperfect foresight and in what ways is it fragile?

I don't have a computer science background, so maybe this is just basic undergraduate material, but it seems like something such as this must be out there as a review paper, book chapter, or some such thing.

After that, look for papers about implementation vs. interface inheritance, and Liskov & Wing's work on subtyping and substitution.

language-neutral
So we're talking about OO Analysis and OO Design, not really about programming languages.
comp.object has some discussions that might be of interest.

everything-is-an-object premise
Is that "everything-is-an-object" in my software, or "everything-is-an-object" in reality?
"It should be clear to anyone that models of the world are completely different from models of software. The world does not consist of objects sending each other messages, and we would have to be seriously mesmerised by object jargon to believe that it does." Designing Object Systems

it seems like something such as this must be out there
Maybe. On the other hand what would someone have-to-gain from writing a multi-perspective critique (even without considering how difficult it would be to do)? More likely Procedural vs OO, or Functional vs OO, or Relational vs OO...

Search for the "fragile base class problem", or the Open-Closed principle.

In my field, review articles tend to get written periodically on topics which have received long term interest (there is even a journal devoted to them: SIAM Review), and they can be a really great way to get acquainted with an area of research. Some of them are so well written and do such a good job of synthesizing the available results and collecting the important open problems that they are "modern classics" in there own right.

I was hoping to get more "hard facts," and fewer anecdotes and opinions, but if I wanted to start a heated debate, I might have asked something like, "It seems like everyone is still obsessed with objects. Even the FP people are jumping on the bandwagon with Ocaml, O'Haskell, Moby and I am sure others. Will OOP rule the world? If you think so, why do think so and if not, why not?"

In response to Isaac:

So we're talking about OO Analysis and OO Design, not really about programming languages. I guess you're right. I was thinking about it from the standpoint that any given programming language is an imperfect attempt to realize some idealization and by "language-neutral" I meant that I was interested in the merits of the idealization itself.

Is that "everything-is-an-object" in my software, or "everything-is-an-object" in reality? Actually, more like in mathematical models of programs. It seems to me that set and graph theory could aptly model the OOP at some level and I thought people would have proved things like the conditions required for the existence of a hierarchical organization of objects (i.e. when is OOP even possible), the properties of an object hierarchy that minimize some useful metric, like non-orthogonality, (i.e. when have you done the best you can), the existence of a sequence of atomic modifications to a hierarchy that leads to a structure which minimizes some metric (i.e. can refactoring always lead us to the best design, or is the final program very sensitive to the initial program).

You'd think it would be clear what was meant by object oriented by-now. But it still seems to depend on who you ask: classes with inheritance, or no-classes but prototypical objects with delegation, or encapsulation (but what's specifically OO about good-old information-hiding?)

Smalltalk is not only NOT its syntax or the class library, it is not even about classes. I'm sorry that I long ago coined the term "objects" for this topic because it gets many people to focus on the lesser idea.

The big idea is "messaging" -- that is what the kernal of Smalltalk/Squeak is all about (and it's something that was never quite completed in our Xerox PARC phase).

Oh, okay, message-passing. So the concurrent functional language Erlang has the essential characteristic of OO. This is sooo postmodern.

Even the FP people are jumping on the bandwagon with Ocaml, O'Haskell, Moby?
Maybe. You can also find examples of OO languages being extended with things characteristic of FP (Nice, Pizza). Maybe it's the postmodern preference for multiplicity over uniformity - let's learn multi-paradigm programming with Mozart/Oz.
Although many languages have constructs that support OO programming, they aren't necessarily used and when they are used it isn't necessarily in a way that could be described as OO. Nobody is that surprised to see C++/Java used as procedural programming languages. Sadly I've also seen the "pure" OO language Smalltalk used to write "pure" procedural code. I guess that's postmodern too.

Hundreds of books are now published on OO. Kristen found that most of these books did not do a good job in teaching the fundamental concepts of OO. Many of us agreed with him (Kristen Nygaard)

I'm looking for a good language-neutral (if you believe in such things) critique of the object-oriented programming paradigm....For example, what are the difficulties, if there are any, with the everything-is-an-object premise?

You might find the following talk
http://pobox.com/~oleg/ftp/papers/MTR2001-Subtyping-talk.ps.gz
and the corresponding paper
http://pobox.com/~oleg/ftp/papers/Subtyping-OOP.ps.gz

rather relevant to your question. The paper and the talk are complementary. In particular, the talk uses pseudo-code specifically to demonstrate that breaking of the separation between interface and implementation is inherent in any OOP system. The paper and the talk also try to make the point that by considering everything an object, we miss good design choices. The talk was presented at the International Monterey Workshop on Software Engineering, in June 2001.

The following web site is another collection of links about "theoretical" and "practical" drawbacks of OOP
http://pobox.com/~oleg/ftp/Computation/Subtyping/References.html

A couple of the Reference quotations are maybe just a little bit selective ;-)
John K. Ousterhout also wrote: Nonetheless, object oriented programming does provide at least two useful features. The first is encapsulation... The second useful feature is interface inheritance

"The thrust of the paper however is on productivity failure and on the reluctance of OOP proponents to back their enthusiasm with hard, empirical data."
I would suggest his target is wider than OOP Proponents. Henry Ledgard concluded the article: It is time we uncover our eyes and face the software dilemma we have today — an industry with no scientific measure of productivity, just emperors with no clothes.

In this question, I am wondering if there are any existence theorems and what are the sufficient conditions for existence of a hierarchical structuring of my data and operations. Most likely, this is trivially obvious, but what I was imagining is that if decomposing your problem into data-method hierarchies was like factoring a polynomial into _real_ factors, then you may not always be able to do it because "the unfactored polynomial may not have all real roots." That is to say, there is some design dimension (i.e. the imaginary axis of the complex plane for the real polynomial roots example) in which you cannot move, but that constraint makes the problem unsolvable. Is OOD "rich enough" to factor every program? If it isn't, then what is the "characterstic equation" which discriminates the required field over which to perform the factorization?

Can I have a large problem which is so twisted and complicated that even though it takes thousands of lines of code, there is no way to simplify it by organizing groups of data and methods into hierarchies. If not, why not?

Maybe a trivial small example of this would be very simple program which performs a single operation, F, requiring two independent pieces of data, A and B: P = F[A,B]. By assumption, A is not a subtype or subclass of B and visa versa. Who owns F? Maybe some abstract binary operator type, but nothing relevant to smplifying the program. It seems like it is pretty much "factored," but there is no need or room for OOP. It's just a trivial program, so it's hardly surprising, but how complicated can A, B and F get before OOP will "kick-in" to help simplify things?

It might seem that I am looking "too closely" and cannot see the forest for the trees, but then I would ask how close is too close to look in order for OOP to be applied? Do some problems have an inherently large "fractal dimension," which means that no matter how far or how close you look, the problem is still too twisted to factor with OOP?

MTR2001-Subtyping-talk, p 15-1: "As the empirical evidence shows, this indeed makes OOP code more difficult to develop and debug, compared to the other alternatives." Which empirical evidence were you referring to?

Hatton, L., "Does OO sync with how we think?" is one example. Shajan Miah's site, cites many empirical studies, for instance, in Chapter 3, Section 2.2.

Furthermore, note the following quotation: "Cypher and Smith (1995) found in user studies that inheritance hierarchies cause difficulty for children. Even among professional programmers, researchers have found that full-edged object- oriented programming is not necessarily natural (Deetienne, 1990; Glass, 1995)." which appeared in
J.F. Pane, C.A. Ratanamahatana, and B.A. Myers, "Studying the Language and Structure in Non-Programmers' Solutions to Programming Problems," International Journal of Human-Computer Studies, vol. 54, no. 2, February 2001, pp. 237-264.
http://www-2.cs.cmu.edu/~pane/IJHCS.html

The paper Subtyping-OOP.ps.gz indeed doesn't tell more than the Subtyping site. I believe however that the paper is written better. BTW, I just tried to view the file Subtyping-OOP.ps.gz as it is with gv, and encountered no problems. gv is based on Ghostscript.

As Henry Ledgard wrote there really isn't empirical evidence to support OO claims; on-the-other-hand there isn't empirical evidence to refute them.
The same point has been made specifically about implementation inheritance. Henry Ledgard mentioned an empirical study: the 130,000 lines of C++ were "developed using the Shlaer-Mellor method. From this study, we found that there was little use of OO constructs such as inheritance and, therefore, polymorphism."
So they used an OO design method and created a system which didn't use implementation inheritance much. What does that tell us about how central implementation-inheritance is to OO?

The "experienced" OO programmers in the Detienne study (as quoted) "were trained in OO for several weeks". They "had difficulties in appropriately structuring the classes." 12 years later shouldn't we be comparing the programmers who used Smalltalk and then Java over the last 10 years, against similarly experienced C programmers? (It's probably a great time to do a comparison study, there are plenty of experienced programmers with time to spare).

researchers have found that full-fledged object-oriented programming is not necessarily natural
Why hedge? It isn't natural! Programming isn't "natural" ;-)

Researchers also found "Some aspects of object-oriented programming were apparent in the participants' solutions. Entities were treated as if they have state and an ability to respond to requests for action." But not inheritance or polymorphism (or mathematical notations).

I lost confidence in Shajan Miah's paper when I checked-out a reference.
"Business people more easily understand the OO paradigm. They think in terms of objects... Similar statements can be found in many popular text books, e.g. ... Wirfs-Brock, Wilkerson, & Weiner (1990,pp. 10-11).
Wirfs-Brock p10 "Object-oriented design makes implementation easier by improving the ability of the designer to communicate with the implementor." That is a very different statement!

The paper stretches the meaning of even the sillier things that have been said about OO: "The way of thinking is more natural for most people than the techniques of structured analysis and design. After all, the world consists of objects." becomes "it should be natural for developers and users to map the problem into objects and into classification hierarchies". That is a very different statement!

Shajan Miah's paper is about data-modelling, it isn't about programming. Maybe that's why it selects quotes from OO Analysis and not from OO Design? "But the idea of an object is a programming idea" (Michael Jackson making fun of OO Analysis). Wirfs-Brock are clear "abstraction is psychologically necessary and natural; abstraction is crucial to how we understand the world." Abstraction, not objects.

Why hedge? It isn't natural! Programming isn't "natural" ;-)

I agree. The problem is that OOP is often being hyped as "closer to the real world" - as if this makes it natural (implying it's easier to program this way, I guess).

When I teach OOP I always try to make sure students realize we are talking about software abstractions - and these are "natural" if they make sense from a software design pov.

Of course, theoretical aspects of programming language design can be discussed sensibly without empirical evidence. Once we claim that it makes a difference in the world we can only substantiate the claim empirically. Dirty work, but I wish someone would do it ;-)

object oriented hype
We're smart. We can laugh at the hype, dismiss it, and take a long-hard-look at the many theoretical and practical problems of OO. There's a real issue somewhere in Shajan Miah's paper about the relative merits of hierachical/OO and relational modelling. There's a real issue in Oleg's paper about subclass/subtype confusion.

OOP is often being hyped as "closer to the real world"
"the development of object-oriented languages... this turn of events has led computer science squarely into the business of doing research in ontology." p44 On the Origin of Objects
I seem to remember that relational modelling led William Kent (Data and Reality. North-Holland, 1978) into the same business.

The world simply doesn't come all chopped up into nice neat categories, to be selected among by peripatetic critters - as if objects were potted plants in God's nursery, with the categories conveniently inscribed on white plastic labels.

OOPSLA annual conference papers, 2002, 2001, 2000, ...

ECOOP annual conference papers

POPL annual conference papers

As Henry Ledgard [1] wrote there really isn't empirical evidence to support OO claims; on-the-other-hand there isn't empirical evidence to refute them.

I'm afraid I don't think that it's our job to refute OOP claims. I believe it's the job of OOP proponents to submit convincing evidence in support of their claims. If you announce tomorrow that you determined that P = NP or have designed a unified theory of gravitational and electromagnetic forces, we'd like to see a proof: a polynomial-time TSP algorithm or a convincing argument that your unified field theory is consistent with all available experimental data and offers new verifiable predictions. It's not we who should refute your arguments; it's you who should convince the rest of us. I believe science is quite different from law: under law, one is innocent until proven guilty. In science, every new theory is presumed "guilty" until proven otherwise.

/researchers have found that full-fledged object-oriented programming is not necessarily natural/ Why hedge? It isn't natural! Programming isn't "natural" ;-)

I believe you and J.F. Pane take the word "natural" to mean different things. You appear to be using the common meaning for "natural". It's debatable if programming is natural in that sense. A dance of a bee or a chieftain of a prehistoric tribe instructing his tribesmen about ambushing a mammoth or a neighboring tribe can be considered examples of "programming." One could further add that the bee dance is an example of a "declarative programming" whereas chieftain's instructions are imperative programming. This debate seems to be beside the point however with regards to the above quotation: J.F.Pane and Brad Myers define "natural programming" a narrow, specific, quantifiable sense.

MTR2001-Subtyping-talk, p 15-1 As the empirical evidence shows, this indeed makes OOP code more difficult to develop and debug, compared to the other alternatives.
I would suggest that the evidence presented doesn't support this claim.
We probably disagree about that ;-)

is not necessarily natural
J.F.Pane and Brad Myers seem to be paraphrasing what Detienne said 10 years earlier (there's some more of it in the Shajan Miah paper); so it doesn't matter what they define as "natural".

I think we agree that "natural" has so many meanings that it's plain unhelpful in this kind of discussion. You could correctly claim that programming is natural because it sure isn't super-natural ;-)

Let's add natural - along with intuitive - to the list of words which should not be used without consulting a dictionary.

These findings seem reasonable to me: A Review of Experimental Investigations into Object-Oriented Technology.

... not all OO design issues appear to have been considered by empirical researchers. This review has also highlighted a preoccupation with a single OO mechanism, namely inheritance, which is considered of diminishing importance by the OO community.

The Hatton study seems good, I'd like to read it. Even then "Hatton expressed reservations about how much the reported problems related specifically to OO and how much they relate to C++."

From "A Review of Experimental Investigations into Object-Oriented Technology"

not all OO design issues appear to have been considered by empirical researchers. This review has also highlighted a /preoccupation/ with a single OO mechanism, namely inheritance, which is considered of diminishing importance by the OO community.

Thank you for the reference to the report "Review of Experimental Investigations" and other references.

Again, from "A Review of Experimental Investigations into Object-Oriented Technology"

Instead, OOT workers place more emphasis upon other mechanisms such as composition, components, frameworks, architectural styles and design patterns.

I agree with Oleg here too. To me, this screems out that the essential character of OOP languages that differentiates them from languages like ML, for instance, has proven in practice to be inappropriate for many problems of interest.

It doesn't seem like the OO FAQ supports this notion, but in addition to objects as instances of subclasses or subtypes (i.e. inheritance), don't peope also refer to objects merely as encapsulations of state and methods which you essentially interact with like a server on a network? I think was one of the ideas in the original Smalltalk work, that a program should be composed of little programs which are themselves composed of little programs which all talk to each other only through messages passed between them all. Is there another word for this sort of "object"? It seems like a fancy module system to me, but then I am largely "ignorant" on this subject (but trying to learn!).

OO is a moving target
I'm sympathetic to this viewpoint.

In science, every new theory is presumed "guilty"
In technology, every new technique is judged by the marketplace & mindshare!
No innocent & guilty.
No right & wrong.
Just success & failure.

my arguments against OOP
Your work seemed fine. As-you-say it is well known that "inheritance is not sub-typing" Designing Object Systems, 1994. Smalltalk inheritance is motivated by white-box code-sharing: Set doesn't subclass Bag, the implementations are different; hashtable classes subclass Set to share code. Confusing this with sub-typing is indeed a big mistake ;-)

The quotes do amuse me: "while opinions concerning the benefits of OOSD abound in OO literature, there is little proof of it's superiority" sounds pretty conclusive until it-turns-out this was the motivation for an internet survey of developers attitudes. The conclusion of the survey was "the hype surrounding OOSD looks more like reality and that adopting OOSD may indeed be worth the related time, effort, and cost." Very different from the quote selected for the paper.

don't people also refer to objects merely as
Jonathan Rees' explanation is concise.

talk to each other only through messages
How parochial of me! Alan Kay designed Smalltalk, have a look at what he says.
This Survey of OOPL is concise.

a fancy module system
A little like that - modules are usually compilation units as well - an implementation of user-defined Abstract Data Types, plus identity? Languages trying to grab some OO hype often described themselves as object-based; maybe #1 in Rees' list. Even Visual Basic 6 became object-based.

Objects and classes versus modules sums things up - don't miss the last slide ;-)

See: Why I Prefer Procedural/Relational

Also note that many heavy OO proponents agree that modeling with many hierarchical or nested taxonomies is a dead-end goal, being that the real world usually does not care about nor follow a tree in real life. Thus, "OO == Trees" is kind of a misnomer, except maybe for a "flatter" form of polymorphism.

Research reports, Empirical Software Engineering journal, Empirical Studies of Programmers workshops.