He literally gives extensive primary source citations to show that the originators of OOP presented this class-domain correspondence as the correct way to think about and do OOP. Bjarne Stroustrup is not just some random guy.

> He literally gives extensive primary source citations to show that the originators of OOP presented this class-domain correspondence

In case of Dahl/Nygaard it seems logical since their work focus was on simulation. Simula I was mostly a language suited to build discrete-event simulations. Simula 67, which introduced the main features we subsume under "Object-Orientation" today, was conceived as a general-purpose language, but still Dahl and Nygaard mostly used it for building simulations. It would be wrong to conclude that they recommended a class-domain correspondence for the general case.

> Bjarne Stroustrup is not just some random guy

Sure, but he was a Simula user himself for distributed systems simulation during his PhD research at Cambridge University. And he learned Simula during his undergraduate education at Aarhus, where he also took lectures with Nygaard (a simulation guy as well). So also here, not surprising that he used examples with class-domain correspondence. But there was also a slide in the talk where Stroustrup explicitly stated that there are other valid uses of OO than using it for modeling domains.

Stroustrup's starting-point (page 13) is abstract-data-types not a compile-time-hierarchy —

"Consider defining a type 'shape' for use in a graphics system. Assume for the moment that the system has to support circles, triangles, and squares. Assume also that you have some classes … You might define a shape like this … This is a mess. …"

Then —

"The problem is that there is no distinction between the general properties of any shape … and the properties of a specific shape … The ability to express this distinction and take advantage of it defines object-oriented programming. …

The programming paradigm is: Decide which classes you want; provide a full set of operations for each class; make commonality explicit by using inheritance. …

Where there is no such commonality, data abstraction suffices."

The source citations are facts. We can check that Alan Kay "The Early History of Smalltalk" shows this on page 82:

"Unfortunately, inheritance — though an incredibly powerful technique — has turned out to be very difficult for novices (and even professionals) to deal with."

When the presenter tells us — 13:45 "he was already saying he kind of soured on it" — that is not a fact, it's speculation. That speculation does not seem to be supported by what follows in "The Early History of Smalltalk".

One page later — "There were a variety of strong desires for a real inheritance mechanism from Adele and me, from Larry Tesler, who was working on desktop publishing, and from the grad students." page 83

And "A word about inheritance. … By the time Smalltalk-76 came along, Dan Ingalls had come up with a scheme that was Simula-like in it's semantics but could be incrementally changed on the fly to be in accord with our goals of close interaction. I was not completely thrilled with it because it seemed that we needed a better theory about inheritance entirely (and still do). … But no comprehensive and clean multiple inheritance scheme appeared that was compelling enough to surmount Dan's original Simula-like design." page 84

Is it fair to blame all of OOP for C++?