The Power of Interoperability: Why Objects Are Inevitable (2013) [pdf]

Indeed; I have had the pleasure of having correspondence with Dr. Aldrich in the past. I had interest in implementing a static compiler for CMU's Plaid programming language, but found Go sufficient at the time. He also became involved with development of the Wyvern programming language. Nonetheless, he is well versed in programming language design and theory as that is his area of interest. It would be hard to imagine any related ignorance on his part.

I agree with the idea that the abstractions provided are "inevitable." I disagree with the idea that the way we're using them is optimal.

I've just spent time in my code reducing polymorphic classes into simpler type identifier + record combinations. The rationale I am going by is that every class I introduce proliferates new symbols: the class definition, the instances, the methods, the values, the references to yet further symbols. Each time I introduce new symbols I bulk up the code and diffuse its meaning; the meaning of these symbols exists in the class, not at the call site. Thus, everything in a class definition is doing its job correctly as long as you want the class to be a true "black box" that hides behind the symbols it provides.

But in many situations, the algorithm is basically "business logic" and conveys the most meaning when inlined at the call site: "Given this type of data, do this. Otherwise, do that." This type of algorithm assumes a schema onto the data, which is usually our true intention; having determined the schema, we can cease further indirection and begin our actual computation. And in this code, ADTs become less important, because we've already used those to query for the data; when we have the queries abstracted, we can stop. We don't need to abstract the meaning any further. Relational database modelling is analogous; when the data is normalized, it's very indirect, yet also very simple. And this pattern can be followed from within a program as well.

Consider the "composable component-entity" model that has become somewhat of a cargo cult fad. These systems generally understand the entity as a record of "which components are used/where to find them/how they fit together". The implication is that a definite schema of "types of components and their properties" exists at or near the top level, and entities do not hide arbitrary blobs of data and functionality in deep recesses, as results when trying to build from class inheritance. Since the concept is poorly defined, actual implementations are all over the place, of course, but the general direction of it is towards flat/primitive/normalized.

The result I got from killing off some classes and inlining their functionality was that I found some lurking unused variables, clarified the top-level, improved the code's flexibility, and reduced total lines of code. So at least in this instance I seem to be on the right track.

I don't think this is really an argument from authority since I'm not saying 'he's right because he has a PhD and teaches at a renowned university'. I'm saying that assuming he's ignorant of FP given both what he says in the paper and his background is silly and shallow.

It's not really fair to say that Aldrich 'misses' a discussion of object thinking, he just chooses to put the focus of that particular paper elsewhere - this is from the intro

Some of the advantages of object-oriented programming may be psychological in nature. For example, Schwill argues that “the object-oriented paradigm...is consistent with the natural way of human thinking” [28]. Such explanations may be important, but they are out of scope in this inquiry; I am instead in- terested in whether there might be significant technical advantages of object-oriented programming.

and

This success raises a natural question: Why has object-oriented programming been successful in practice?

> Do you really believe the author ... is simply clueless about functional programming?

I believe that his paper's descriptions of technical advantages of OO are not actually about OO, and instead are about FP and interfaces -- what he calls "service abstractions".

Notice this: when he describes ADTs, he glosses over their power; when he describes the evolution of object code, he glosses over the evolution of interfaces; when he describes messaging, he glosses over protocol endpoints.

IMHO his paper mostly glosses over all the actual technical advantages of OO vs. other approaches, namely OO state encapsulation, OO black boxing, OO inheritance, and OO composition.

He writes that the "key technical characteristic" of OOP is dynamic dispatch, and "is essential to supporting independent, interoperating extensions". OOP's key technical characteristic is not dynamic dispatch -- it's black boxing of data + state + methods. Moreover, dynamic dispatch is not essential to supporting extensions as he claims. To top it off, FP easily does dynamic dispatch by using higher level functions and type classes if you like.

Given the difference in both OOP and FP, I agree it certainly would be an interesting contrast to explore. Especially now, as FP is becoming more mainstream.