The Big OOPs: Anatomy of a Thirty-Five Year Mistake

bjarne (creator of c++) has a quote about this:

Unified function call: The notational distinction between x.f(y) and f(x,y) comes from the flawed OO notion that there always is a single most important object for an operation. I made a mistake adopting that. It was a shallow understanding at the time (but extremely fashionable). Even then, I pointed to sqrt(2) and x+y as examples of problems caused by that view.

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p19...

> Suddenly clicked for me why some people/languages prefer doThing(X, Y) vs. X.doThing(Y)

It's when you start writing ThingDoer.doThing(X, Y) that you begin questioning things.

More info on "The Expression Problem" https://en.wikipedia.org/wiki/Expression_problem

There are OOP languages that use doThing(X, Y), though.

Ada, Julia, Dylan, Common Lisp for example.

Yet another example why people shouldn't put programming paradigms all into the same basket.

You can do ECS in any programming paradigm. It’s not incompatible with OO at all. There’s no need for the object model to be congruent to a static representation of a domain, in a line-of-business app it is much better for it to be congruent to workflow and processing.

Heck I’ve even done ECS in Rails for exactly this reason.

I never accepted the Java/C++ bastardisation of OOP and still think that Erlang is the most OO language, since encapsulation and message passing is so natural.

ECS is a part of OOP, hence why languages like Objective-C introduced protocols, while others like C++ and Eiffel went the multiple inheritance route.

Even Smalltalk, post Smalltalk-80 implementations eventually added traits, alongside its single inheritance model.

Thank you for this summary. I'm a hobbyist programmer and want to watch this, but having a few concepts to hang my hat helps contextualize this for me.

No offense, but this reads as a GPT generated summary.

Similar experience. I would be the one the entire team would turn to when a really hard problem to debug came up. Yet, when I would say that OOP is not great and is over-complicating the code, I would be scoffed at. I never could reconcile how I was "leaned on" to fix things, but ignored in proposing different paradigms.

I recently read a quote, paraphrasing, Orthodoxy is a poor man's substitute for moral superiority.

This is a pervasive phenomenon in programming. Many times suboptimal solutions remain for a long time because, well, it does solve the problem. Once you are taught X by authoritative figures, you tend to lean on it. It takes experience and an open mind to do anything else.

The use of GOTO is another example. Yes, you probably wouldn't want in your codebase, but the overzealousness against it removes expressions like break statements or multiple return statements from languages.

There is no such thing as non-OO Python, the language is like Smalltalk, everything is an object, even plain numeric values.

This wasn't true with original Python, however since new style classes became the default type system, everything is indeed an object.

So for the anti-OOP folks out there using languages like Python as an example,

    Python 3.13.0 (tags/v3.13.0:60403a5, Oct  7 2024, 09:38:07) [MSC v.1941 64 bit (AMD64)] on win32
    Type "help", "copyright", "credits" or "license" for more information.
    >>> x = 23
    >>> type(x)
    <class 'int'>
    >>> dir(x)
    ['__abs__', '__add__', '__and__', '__bool__', '__ceil__', '__class__', '__delattr__', '__dir__', '__divmod__', '__doc__', '__eq__', '__float__', '__floor__', '__floordiv__', '__format__', '__ge__', '__getattribute__', '__getnewargs__', '__getstate__', '__gt__', '__hash__', '__index__', '__init__', '__init_subclass__', '__int__', '__invert__', '__le__', '__lshift__', '__lt__', '__mod__', '__mul__', '__ne__', '__neg__', '__new__', '__or__', '__pos__', '__pow__', '__radd__', '__rand__', '__rdivmod__', '__reduce__', '__reduce_ex__', '__repr__', '__rfloordiv__', '__rlshift__', '__rmod__', '__rmul__', '__ror__', '__round__', '__rpow__', '__rrshift__', '__rshift__', '__rsub__', '__rtruediv__', '__rxor__', '__setattr__', '__sizeof__', '__str__', '__sub__', '__subclasshook__', '__truediv__', '__trunc__', '__xor__', 'as_integer_ratio', 'bit_count', 'bit_length', 'conjugate', 'denominator', 'from_bytes', 'imag', 'is_integer', 'numerator', 'real', 'to_bytes']
    >>>

I'm a bit confused. What does any of this have to do with the central thesis of the talk? ("Compile time hierarchies of encapsulation that match the domain model were a mistake")

I understand that OOP is a somewhat diluted term nowdays, meaning different things to different people and in different contexts/communities, but the author spent more than enough time clarifying in excruciating detail what he was talking about.

Did you spend even 3 Minutes trying to understand what the talk was about?

And here: https://news.ycombinator.com/item?id=44603205

How is this "the other end of the spectrum"? The Typestate pattern described at https://geeklaunch.io/blog/make-invalid-states-unrepresentab... (especially wrt. its genericized variety that's quite commonly used in Rust) is precisely a "compile-time hierarchy of encapsulation that matches the domain model", to use Casey Muratori's term for what he's talking about. It's literally inheritance-based OOP in a trenchcoat.

There is a good book on DDD in F#, Domain Modelling Made Functional

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.

It's funny because I read this comment and then watched the video, and it's like the first 15 minutes of the talk are dedicated to debunking this exact comment. Freaky.

Did you actually watch it? He talks A LOT more about Simula and C++ than Smalltalk. He goes back to the original sources: Kristen Nygaard and Bjarne Stroustrup. Seems odd to focus on Smalltalk when that’s not what the talk was about.

Except that his talk is not anti-OOP. It's anti-a-specific-way of using OOP. Namely representing the Domain Model as the compile time hierarchy. He goes to great lengths that he himself uses OOP concepts in his code. OOP wasn't a mistake per-se. The mainstream way of using as promulgated by a number of experts was the mistake.

I had whisper make a transcript and skimmed some but I ended up watching the talk at ~1.5x speed in the end anyway. https://pastebin.com/EngTq9ZA If you want the timestamps kept in I can paste that too.

https://rentry.co/2sky3whm

the video does a deep dive into the history of OOP which is very interesting if you are into that sort of thing.

About every video on YouTube has a transcript, usually a button at the bottom of the description.

> I think his definition of OO is different to what we've got used to. Perhaps his definition needs a different name.

I've seen "OOP" used to mean different things. For example, sometimes it's said about a language, and sometimes it's unrelated to language features and simply about the "style" or design/architecture/organization of a codebase (Some people say some C codebases are "object oriented", usually because they use either vtables or function pointers, or/and because they use opaque handles).

Even when talking about "OOP as a programming language descriptor", I've seen it used to mean different things. For example, a lot of people say rust is not object-oriented. But rust lets you define data types, and lets you define methods on data types, and has a language feature to let you create a pointer+vtable construct based on what can reasonably be called an interface (A "trait" in rust). The "only" things it's lacking are either ergonomics or inheritance, or possibly a culture of OOP. So one definition of "OOP" could be "A programming language that has inheritance as a language feature". But some people disagree with that, even when using it as a descriptor of programming languages. They might think it's actually about message passing, or encapsulation, or a combination, etc etc.

And when talking about "style"/design, it can also mean different things. In the talk this post is about, the speaker mentions "compile time hierarchies of encapsulation that match the domain model". I've seen teachers in university teach OOP as a way of modelling the "real world", and say that inheritance should be a semantic "is-a" relationship. I think that's the sort of thing the talk is about. But like I mentioned above, some people disagree and think an OOP codebase does not need to be a compile time hierarchy that represents the domain model, it can be used simply as a mechanism for polymorphism or as a way of code reuse.

Anyways, what I mean to say is that I don't think arguing about the specifics of what "OOP" means in the abstract very useful, and that since in this particular piece the author took the time to explicitly call out what they mean that we should probably stick to that.

>I think his definition of OO is different to what we've got used to.

No. His definition is exactly what people are taught OOP is. It is what I was taught, it is what I have seen taught, it is what I see people mean when they say they are doing OOP.

> Perhaps his definition needs a different name.

No. Your definition needs a different name. Polymorphic functions are not OOP. If you give someone standard Julia code, a language entirely built around polymorphic functions, they would tell you that it is a lot of things, except nobody would call it OOP.

Importantly polymorphic functions work without class hierarchies. And calling anything without class hierarchies "OOP" is insane.

what is your reasoning? if you make your own object system, that is indeed polymorphic. do you now feel the need to model the world in your application?

Really short: ECS existed in the earliest implementations of OOP in 1963 and was being used in the software he showed.

When OOP went mainstream it pretty much was entirely about "compile time hierarchy of encapsulation that matches the domain model" and nothing else. His opinion is the standard way of doing OOP is a bad match for lots of software problems but became the one-size-fits-all solution as a result of ignorance.

Also he claims that history is being rewritten to some extent to say this wasn't the case and there was never a heavy emphasis on doing things that way.

OOPs = "object-oriented programming", BUT it's a more restrained and thoughtful complaint than just "objects suck" or "inheritance sucks". He cabins it pretty clearly at 11:00 minutes in: "compile-time hierarchy of encapsulation that matches the domain model was a mistake"

In short, in my opinion:

- Encapsulation / interfaces is a good idea, a continuation of the earlier ideas of structured programming.

- Mutable state strewn uncontrollably everywhere is bad idea, even in a single-threaded case.

- Inheritance-based polymorphism is painful, both in the multiple (C++) and single (Java) inheritance cases. Composable interfaces / traits / typeclasses without overriding methods are logically and much more useful.

Basically his “35-year mistake” thesis is that we almost had ECS, the entity/component/system pattern, in 01963 with Sketchpad, but it took until 01998. He explains this near the end of the talk proper, and explains how Looking Glass in 01998 introduced the pattern in Ultima II Underworld, but really introduced it with Tom Leonard’s Thief: The Dark Project. Later though he seems to be saying that he's not sure ECS is actually a good idea, but he thinks encapsulation is, if not a bad idea, at least an idea that should be applied carefully to keep it from getting in your way, and definitely not in a way that reflects a division among problem-domain objects such as cars, trucks, bridges, circular arcs, lanterns, etc.

The 35 year mistake was the idea that in order to have a well structured program, your compile time hierarchies have to represent real world relationships.

The talk traces that mistake to Simula, where it was appropriately used, because it was intended to simulate the real world hierarchies. Then to C++ where it started to become used inappropriately, then to Java, where it became a universal Praxis to model all real world relationship as compile time hierarchies.

Stroustrup took out object hierarchy introspection feature that was available before, which turned out to be a pretty handy feature that people kept trying to reimplement.

I don't know, but given the page, I think it is OOPS.

Object oriented programming.