15 ms·

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

234 points by SerCe 1y ago

https://www.youtube.com/watch?v=wo84LFzx5nI https://www.youtube.com/watch?v=wo84LFzx5nI

Rochus 1y ago
Entertaining. The presenter obviously doesn't like the class hierarchy to correspond to the domain model. He seems to think that this was an essential feature of OOP, supported by some quotations by Smalltalk exponents. But not even the Smalltalk world could agree on what OOP actually is (just compare the statements by Kay with the actual architecture of Smalltalk-76ff) and as quickly as Smalltalk lost its significance, there is no need to mention it further. I would rather look at a reputable industry organization such as IEEE, which even publishes its own standards and best practices, what OOP is about. E.g. the OOP Milestone (see https://ethw.org/Milestones:Object-Oriented_Programming,_1961-1967 https://ethw.org/Milestones:Object-Oriented_Programming,_196...) which names Simula 67 the first OO language, specifies OO as "the combination of three main features: 1) encapsulation of data and code 2) inheritance and late binding 3) dynamic object generation." No mention of the class hierarchy should correspond to the domain model. So maybe we should just not mix up a programming paradigm with how it is used by some folks in practice? The fact that the loudest proponents of a paradigm are not usually those who apply it in practice remains true even today. Takes far less than 2.5 hours to state.
- asa400 1y ago
  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.
  - t420mom 1y ago
    Is it fair to blame all of OOP for C++?
    - anp 1y ago
      Maybe not fair, but it’s pretty normal for people to assess paradigms based on their most popular implementations.
    - throwawaymaths 1y ago
      yes, because java and c# (and others, python to a certain extent) basically copied it. even ruby, which at its core is about "message passing" sure does a hell of a lot to hide that and make it feel c++ ish. i would bet at least 25% of ruby practitioners arent aware that message passing is happening.
      - deleted 1y ago
        [deleted]
      - JohnMakin 1y ago
        at least python gives the flexibility to opt out of OOP, whereas in java, literally everything is an Object
        throwawaymaths 1y ago
        that's why i said "to a certain extent" for python!!
        Spivak 1y ago
        What do you mean by this? Because everything in Python is object, even classes and functions are objects. Do you just mean that Python lets you write functions not as part of a class? Because yeah there's the public static void main meme but static functions attached to a class is basically equivalent to Python free functions being attached to a module object.
        fc417fc802 1y ago
        If I call something a function does that mean I'm "doing functional programming" any time I use it? I use both C++ and Python but I wouldn't describe any of what I write as "object oriented".
  - Rochus 1y ago
    > 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.
  - igouy 1y ago
    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
  - igouy 1y ago
    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."
- dimal 1y ago
  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.
- deleted 1y ago
  [deleted]
- phendrenad2 1y ago
  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.
lioeters 1y ago
The presentation was recently discussed at: https://news.ycombinator.com/item?id=44596554 https://news.ycombinator.com/item?id=44596554 [video] (37 comments) This current posted link is an article by Casey Muratori with supplementary material on topics to explore further. - Early History of Smalltalk - History of C++ - Development of the Simula Languages - Origins of the APT Language for Automatically Programmed Tools
- Rochus 1y ago
  And here: https://news.ycombinator.com/item?id=44603205 https://news.ycombinator.com/item?id=44603205
  - Rochus 1y ago
    Ok, meanwhile the admins seem to have combined all the comments here, so the link now points to an empty post; and I made this comment a few days (not four hours) ago. So just ignore it.
nottorp 1y ago
Any way to find out what the 35 year mistake was without being "engaged" for hours on that video?
- isotropy 1y ago
  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"
  - ocrow 1y ago
    To unpack that a little, he looks to the writings of the early developers of object oriented programming and identifies the ways this assumption became established. People like Bjarne Stroustrup (developer of C++) took on and promulgated the view that the inheritance hierarchy of classes in an object oriented system can be or should be a literal instantiation of the types of objects from the domain model (e.g. different types of shapes in a drawing program). This is a mistake is because it puts the broad-scale modularization boundaries of a system in the wrong places and makes the system brittle and inflexible. A better approach is one where large scale system boundaries fall along computational capability lines, as exemplified by modern Entity Component Systems. Class hierarchies that rigidly encode domain categorizations don't make for flexible systems. Some of the earliest writers on object encapsulation, e.g. Tony Hoare, Doug Ross, understood this, but later language creators and promoters missed some of the subtleties of their writings and left us with a poor version of object-oriented programming as the accepted default.
    - mariodiana 1y ago
      Is Objective-C discussed at all?
      - tmp10423288442 1y ago
        Only as a brief aside (don't have the timestamp right now) to talking about Smalltalk, which he mostly discusses to argue that Smalltalk was not different from C++ in seeking (most of the time) to model programs in terms of static hierarchies (according to the primary source documentation from the time of Smalltalk's design): > And another thing is if you look at the other branch, > the branch that I'm not really covering very much > in this talk, because again, > we don't program in small talk these days, right? > The closest thing you would get > is maybe something like Objective-C. > If there's some people out there using Objective-C, > you know, like Apple was using that for a little while, > so Objective-C kind of came > from a small talk background as well. Objective-C is basically Smalltalk retrofitted onto C, even more than C++ was Simula retrofitted onto C (before C++ gained template metaprogramming and more modern paradigms), so it makes sense that Muratori doesn't go much into it, given that he doesn't discuss Smalltalk much.
lproven 1y ago
Is there a script or transcript anywhere, for those of us who can read 10x faster than it is possible to understand speech?
- cma 1y ago
  About every video on YouTube has a transcript, usually a button at the bottom of the description.
  - lproven 1y ago
    No help. It's video speed. I can read at several thousand words a minute. So I need the whole transcript in one shot. Then I can read it in 10 or 15 minutes or so, and decide if it's worth watching a 2 hour plus video. The answer is almost always "no".
    - veggieroll 1y ago
      Use yt-dlp to download the transcript.
    - zahlman 1y ago
      A few lines of Javascript in the console can copy that to the clipboard for you. Maybe someone's packaged that up already. (It's on my todo list to look around...)
      - insin 1y ago
        Control Panel for YouTube [1] has an option to add a new "Download" item to the menu in the video Transcript box (which I've just noticed is currently broken, as YouTube must have changed the implementation again recently) Here's a fixed version [2] - run this when the transcript is open and loaded. [1] https://soitis.dev/control-panel-for-youtube https://soitis.dev/control-panel-for-youtube [2] https://gist.github.com/insin/cb938324866c511066bcabe230b6a625 https://gist.github.com/insin/cb938324866c511066bcabe230b6a6...
    - cma 1y ago
masfoobar 1y ago
I enjoyed listening to this talk. In many ways I was aware of the history of OOP but its great to see it in more detail with quotes from known names, etc. I also appreciate the shoutout to Looking Glass Studios and their Thief: the dark project game. I LOVED this game when it came out. Obviously the programmer inside appreciates Thief for its overall design as well. Around 2005 I had to make a graphical shop floor on the web and all product on shelves, etc. Trying to do this in HTML4 with different browsers was a pain, and mostly written in Javascript. During my later time in the project I started to get a feel for AJAX and I wanted to move all my javascript into a library (backend) so I could do more than just an HTML interface. I was thinking OpenGL and other methods or even networking where multiple people could do things together. I started re-writing a VB.NET version of this javascript library and I could not get past the initial design. Remember i'm technically still a junior developer. I was designing the project "the right way" with OOP - inheritence, overrides, etc. It "looked nice" when you view my OOP as a diagram. It starts off well but when you go down the rabbit hole as well as new features it starts to get bloated and messy. In the end I thought about games I was writing in C and viewed what I was doing in a game-like way. I ended up creating each "item" with a unique Id (index) and a bunch of "features" that link to the "item" Id. This way, when rendering, I just look each "feature" update and re-render. It was working suprisingly well. I could then, for each customer using this product, could have their own XML file to store each "object" which was simply an "item" with "features" Obviously, this is all before I had heard of Entity Component Systems (ECS) or Data-oriented Design, and other names. I still treasure that project to this very day as a pure success story. I was porting it over to C# before I decided to leave around 2009. If the pay was better, I could still be working for them today (assuming I get more pay increase as the years passed) It is a reminder that OOP is not be-all-end-all solution.
medmedsalem 1y ago
[flagged]
kristianp 1y ago
And on the other end of the spectrum, you have the proponents of Domain-driven design (DDD)[0], where they use an ML descended language such as F# and the aim is to make invalid states unrepresentable by the program [1] [0] https://fsharpforfunandprofit.com/ddd/ https://fsharpforfunandprofit.com/ddd/ [1] Make invalid states unrepresentable: https://geeklaunch.io/blog/make-invalid-states-unrepresentable/ https://geeklaunch.io/blog/make-invalid-states-unrepresentab...
- zero_shift 1y ago
  There is a good book on DDD in F#, Domain Modelling Made Functional
  - clickety_clack 1y ago
    Yes! I just got a copy of this a couple of days ago. Ive been on a DDD + FP kick recently and it’s leading to some really satisfying solutions.
  - HexDecOctBin 1y ago
    Is there a similar recommended book using ML/OCaml or some other language of the family? i am hesitant to learn F#, knowing Microsoft's tendencies.
    - S04dKHzrKT 1y ago
      There are very few F# specific features used in the book. I imagine you could follow along pretty easily with any other functional language. You can easily use F# for the book and then apply the lessons learned to another language when you're done too. It mainly shows how to use sum types, product types and function composition to implement DDD. I'm not sure what tendencies you're referring to though. F# has been around for 20 years and has only gotten better over time.
- zozbot234 1y ago
  How is this "the other end of the spectrum"? The Typestate pattern described at https://geeklaunch.io/blog/make-invalid-states-unrepresentable/#state-machines-and-state-transitions 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.
deleted 1y ago
[deleted]
cloogshicer 1y ago
Can someone point to a real life example or tutorial/guide of the ECS architecture he proposes? I'd like to learn more about how to implement this.
- adastra22 1y ago
  Like this? https://devlog.hexops.com/2022/lets-build-ecs-part-1/ https://devlog.hexops.com/2022/lets-build-ecs-part-1/
- joeblubaugh 1y ago
  They’re very common in video game programming and visual effects and uncommon elsewhere. I enjoyed this article, though it’s still about using ECS in a simulation / computer graphics context. https://adventures.michaelfbryan.com/posts/ecs-outside-of-games/ https://adventures.michaelfbryan.com/posts/ecs-outside-of-ga...
- jayd16 1y ago
  The two biggest for-sale engines have their implementations as well as what others have posted. Unity ECS (has a pretty good general introduction to ECS) https://docs.unity3d.com/Packages/com.unity.entities@1.3/manual/concepts-ecs.html https://docs.unity3d.com/Packages/com.unity.entities@1.3/man... Unreal https://dev.epicgames.com/documentation/en-us/unreal-engine/overview-of-mass-entity-in-unreal-engine https://dev.epicgames.com/documentation/en-us/unreal-engine/...
- crabmusket 1y ago
  Here's something that I think is in the direction Casey advocates for without being full-blown ECS: https://gamedev.net/blogs/entry/2265481-oop-is-dead-long-live-oop/ https://gamedev.net/blogs/entry/2265481-oop-is-dead-long-liv... As I posted on the video itself: https://news.ycombinator.com/item?id=44611240 https://news.ycombinator.com/item?id=44611240
- dkbrk 1y ago
  It's a bit of a long read, but I think the best introduction is still this [0] and the comments were here [1]. Yes, it's presented in the context of rust and gamedev, but ECS isn't actually specific to a particular programming language or problem domain. [0]: https://kyren.github.io/2018/09/14/rustconf-talk.html https://kyren.github.io/2018/09/14/rustconf-talk.html [1]: https://news.ycombinator.com/item?id=17994464 https://news.ycombinator.com/item?id=17994464
chrisg23 1y ago
This is an excellent talk. It digs really deep into the history of OOP, from 1963 to 1998. The point is that in 1998 the commercial game "Thief" was developed using an entity component system (ECS) architecture and not regular OOP. This is the earliest example he knows of in modern commercial programming. During his research into the history of OOP he discovered that ECS existed as early as 1963, but was largely forgotten and not brought over as a software design concept or methodology when OOP was making its way into new languages and being taught to future programmers. There's lots of reasons for why this happened, and his long talk is going over the history and the key people and coming up with an explanatory narrative.
- lemonberry 1y ago
  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.
- inopinatus 1y ago
  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.
- pjmlp 1y ago
  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.
  - zaphar 1y ago
    I am not sure what the link between ECS and protocols, traits, and multiple inheritance is? ECS is mostly about memory layout not typed interfaces as far as I know.
MantisShrimp90 1y ago
i love casey and I love this talk. Always good to see people outside of academia doing deep research and this corroborates allot of how I have understood the subject. I find it funny that even after he goes into explicit detail about describing oop back to the original sources people either didn't watch it or are just blowing past his research to move the goal post and claim thats not actually what OOP is because they don't want to admit the industry is obsessed with a mistake just like waterfall and are too stockholm syndromed to realize
- zaphar 1y ago
  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.
  - mrkeen 1y ago
    The problem is when you take out mistakes, there's not much left of OOP. We take out 'dog-is-an-animal' inheritance. We take out object-based delegation of responsibility (an object shall know how to draw itself). A Painter will instead draw many fat structs. Code reuse? Per the talk, the guy who stumbled onto this was really looking for a List<> use-case, (not a special kind of Bus/LinkedList hybrid. He was after parametric polymorphism, not inheritance.
  - vkazanov 1y ago
    The problem is that once you exclude domain-specific hierarchy from the discussion, there's not much left of OOP. It's just data + relevant functions. Which is ok. That's all there is, really.
    - mrkeen 1y ago
      And Rich Hickey calls out even that last feature as a mistake, and I tend to agree. https://gist.github.com/reborg/dc8b0c96c397a56668905e2767fd697f#should-i-use-a-namespace-to-bundle-functions-to-model-a-domain-object-like-a-customer-or-product https://gist.github.com/reborg/dc8b0c96c397a56668905e2767fd6...
voidhorse 1y ago
As someone who has always found popular OOP stupid (programming is closer to math, not linguistics—write functional programs!) I'm glad Casey is going out there and giving talks like this. If extensive academic research and extensively documented benefits couldn't convince the industry to abandon OOP in favor of functional style maybe an everyman like Casey finally can. A lot of so-called programmers and systems "engineers" act like religious zealots. Even challenging the ideas of OOP is blasphemy to them, even though there are many legitimate reasons to do so.
- vjvjvjvjghv 1y ago
  I was around when OOP became popular in the 90s. I think it was a huge step forward. Problem is that with almost every useful paradigm at some point consultants and zealots take over and push things to an extreme that doesn't work. And when problems show up, it's because you didn't do it right. Happened with OOP, NoSQL, Agile and probably many others. I don't see how functional style won't go differently.
  - lisbbb 1y ago
    Despite spending untold hours learning and using C++ and Java, I never fully believed that OOP was anything great. It always felt so forced to code everything in terms of classes rather than just modules of code that have similar responsibilities.
    - Jtsummers 1y ago
      You must not mean C++ when you write about having to write everything in terms of classes. Java, yes, with the requirement that the nearest thing to a free standing function is a static method in a class (which becomes in effect a regular old module). But C++? You could, and many did, pretend it was fancy C and only deal with classes when it came to using things like collections and streams (because they were useful).
    - vjvjvjvjghv 1y ago
      The whole code everything in classes idea came up when the purists took over. I (and most reasonable people I know) wrote most of their code in single functions and used instantiable classes only where it made sense. A class with only static methods is basically a module.
DavidPiper 1y ago
So much gold to mine in this talk. Even just this kind of throwaway line buried deep in the Q&A: > I prefer to write code in a verb-oriented way not an object-oriented way. ... It also has to do with what type of system you're making: whether people are going to be adding types to the system more frequently or whether they're going to be adding actions. I tend to find that people add actions more frequently. Suddenly clicked for me why some people/languages prefer doThing(X, Y) vs. X.doThing(Y)
- BoiledCabbage 1y ago
  More info on "The Expression Problem" https://en.wikipedia.org/wiki/Expression_problem https://en.wikipedia.org/wiki/Expression_problem
- pjmlp 1y ago
  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.
  - virgilp 1y ago
    There are a handful of (somewhat exotic) languages that support multiple dispatch - pretty much, all those listed by you. None of the mainstream ones (C++, Java, C# etc) do. (also Common Lisp is hardly a poster child of OOP, at best you can say it's multi-paradigm like Scala)
    - pjmlp 1y ago
      I guess Julia and Clojure are exotic. Since when do OOP languages have to be single paradigm? By then point of view, people should stop complaining about C++ OOP then.
      - virgilp 1y ago
        > Since when do OOP languages have to be single paradigm? What I really meant to say with that was that it's lisp at its core -i.e. if one wants to place it squarely in one single paradigm, imo that one should be "Functional". I was just surprised to see it listed as an example of OOP language, because it's not the most representative one at that.
lisbbb 1y ago
I complained a lot about OOP all throughout my 25 years a developer. I wrote a ton of C++ and then Java and nobody can refute my expertise with those languages. I saw so many people make mistakes using them, particularly with forcing taxonomies into situations that weren't conducive to having them. Then, when I began complaining to my colleagues about my feelings, I was ostracized and accused of "not having a strong enough skillset." In other words, the dogma of the time overrode the Cassandras saying that the emperor had no clothes. Meanwhile, the simple nature of C and even scripting languages was considered out date. The software dev community finally realized how bad things had gotten with Java and then the walls came a tumbling down. I far prefer writing non-OO Python (or minimal use of classes) to anything else these days. I went all around the language world--did projects involving Lua, Clojure, tons of Groovy, then moved on to Functional Java, Kotlin, and Golang.
- hackthemack 1y ago
  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.
- gloomyday 1y ago
  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.
- pjmlp 1y ago
  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'] >>>
rr808 1y ago
I really dont understand his reasoning. If you have a pointer to the base class different implementations are polymorphic and its hidden from the caller. That is the whole point and it means you can have an engine with a base class in a library, then different people can derive from it and use that engine. I think his definition of OO is different to what we've got used to. Perhaps his definition needs a different name.
- henning 1y ago
  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?
- constantcrying 1y ago
  >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.
  - igouy 1y ago
    "The expression problem matrix … In object-oriented languages, it's easy to add new types but difficult to add new operations … Whereas in functional languages, it's easy to add new operations but difficult to add new types" https://eli.thegreenplace.net/2016/the-expression-problem-and-its-solutions/ https://eli.thegreenplace.net/2016/the-expression-problem-an...
  - rr808 1y ago
    OK then in his base class he has function pointers to different implementations. How can you compile a base class Shape with C++ in a library that will have derivations you dont know about?
xg15 1y ago
OOP has lots of flaws and is not a good choice in every context, but I still don't understand the universal hatred it seems to get now. I think OOP techniques made most sense in contexts where data was in memory of long-running processes - think of early versions of MS Office or such. We've since changed into a computing environment in which everything that is not written to disk should be assumed emepheral: UIs are web-based and may jump not just between threads or processes but between entire machines between two user actions. Processes should be assumed to be killed and restarted at any time, etc etc. This means it makes a lot less sense today to keep complicated object graphs in memory - the real object graph has to be represented in persistent storage and the logic inside a process works more like a mathematical function, translating back and forth between the front-end representation (HTML, JSON, etc) and the storage representation (flat files, databases, etc). The "business logic" is just a sub-clause in that function. For that kind of environment, it's obvious why functional or C-style imperative programming would be a better fit. It makes no sense to instantiate a complicated object graph from your input, traverse it once, then destroy it again - and all that again and again for every single user interaction. But that doesn't mean that the paradigm suddenly has always been bad. It's just that the environment changed. Also, there may be other contexts in which it still makes sense, such high-level scripting or game programming.
- constantcrying 1y ago
  Did you spend even 3 Minutes trying to understand what the talk was about?
- nickitolas 1y ago
  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.
tw061023 1y ago
It seems the community is severely overexposed to bad practices and implementations of OOP and conversely severely underexposed to the success stories. 153 comments as of time of writing, let's see. C-F: Java: 21 C++: 31 Python: 23 C#: 2 And yet: Pascal: 1 (!) Delphi: 0 VCL: 0 Winforms: 0 Ruby: 2 (in one comment) This is not a serious conversation about merits of OOP or lack thereof, just like Casey's presentation is not a serious analysis - just a man venting his personal grudges. I get that, it's completely justified - Java has a culture of horrible overengineering and C++ is, well, C++, the object model is not even the worst part of that mess. But still, it feels like there is a lack of voices of people for whom the concept works well. People can and will write horrible atrocities in any language with any methodologies; there is at least one widely used "modern C++" ECS implementation built with STL for example (which itself speaks volumes), and there is a vast universe of completely unreadable FP-style TypeScript code out there written by people far too consumed by what they can do to stop for a second and think if they should. I don't know why Casey chose this particular hill to die on, and I honestly don't care, but we as a community should at least be curious if there are better ways to do our jobs. Sadly, common sense seems to have given way to dogma these days.
nivertech 1y ago
2.5 hours to explain [a concept somewhat similar to] AoS vs SoA? Unlike the mainstream OOP, ECS (Entity Component System) is a niche programming model, even Erlang/OTP is probably more OOP-like than ECS. Same with Agents. But the Software Archeology part was amazing.

234 points by SerCe 1y ago

https://www.youtube.com/watch?v=wo84LFzx5nI https://www.youtube.com/watch?v=wo84LFzx5nI

Entertaining. The presenter obviously doesn't like the class hierarchy to correspond to the domain model. He seems to think that this was an essential feature of OOP, supported by some quotations by Smalltalk exponents. But not even the Smalltalk world could agree on what OOP actually is (just compare the statements by Kay with the actual architecture of Smalltalk-76ff) and as quickly as Smalltalk lost its significance, there is no need to mention it further. I would rather look at a reputable industry organization such as IEEE, which even publishes its own standards and best practices, what OOP is about. E.g. the OOP Milestone (see https://ethw.org/Milestones:Object-Oriented_Programming,_1961-1967 https://ethw.org/Milestones:Object-Oriented_Programming,_196...) which names Simula 67 the first OO language, specifies OO as "the combination of three main features: 1) encapsulation of data and code 2) inheritance and late binding 3) dynamic object generation." No mention of the class hierarchy should correspond to the domain model. So maybe we should just not mix up a programming paradigm with how it is used by some folks in practice? The fact that the loudest proponents of a paradigm are not usually those who apply it in practice remains true even today. Takes far less than 2.5 hours to state.

asa400 1y ago
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.
- t420mom 1y ago
  Is it fair to blame all of OOP for C++?
  - anp 1y ago
    Maybe not fair, but it’s pretty normal for people to assess paradigms based on their most popular implementations.
  - throwawaymaths 1y ago
    yes, because java and c# (and others, python to a certain extent) basically copied it. even ruby, which at its core is about "message passing" sure does a hell of a lot to hide that and make it feel c++ ish. i would bet at least 25% of ruby practitioners arent aware that message passing is happening.
    - deleted 1y ago
      [deleted]
    - JohnMakin 1y ago
      at least python gives the flexibility to opt out of OOP, whereas in java, literally everything is an Object
      - throwawaymaths 1y ago
        that's why i said "to a certain extent" for python!!
      - Spivak 1y ago
        What do you mean by this? Because everything in Python is object, even classes and functions are objects. Do you just mean that Python lets you write functions not as part of a class? Because yeah there's the public static void main meme but static functions attached to a class is basically equivalent to Python free functions being attached to a module object.
        fc417fc802 1y ago
        If I call something a function does that mean I'm "doing functional programming" any time I use it? I use both C++ and Python but I wouldn't describe any of what I write as "object oriented".
- Rochus 1y ago
  > 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.
- igouy 1y ago
  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
- igouy 1y ago
  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."
dimal 1y ago
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.
deleted 1y ago
[deleted]
phendrenad2 1y ago
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.

lioeters 1y ago

The presentation was recently discussed at: https://news.ycombinator.com/item?id=44596554 https://news.ycombinator.com/item?id=44596554 [video] (37 comments) This current posted link is an article by Casey Muratori with supplementary material on topics to explore further. - Early History of Smalltalk - History of C++ - Development of the Simula Languages - Origins of the APT Language for Automatically Programmed Tools

Rochus 1y ago
And here: https://news.ycombinator.com/item?id=44603205 https://news.ycombinator.com/item?id=44603205
- Rochus 1y ago
  Ok, meanwhile the admins seem to have combined all the comments here, so the link now points to an empty post; and I made this comment a few days (not four hours) ago. So just ignore it.

nottorp 1y ago

Any way to find out what the 35 year mistake was without being "engaged" for hours on that video?

isotropy 1y ago
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"
- ocrow 1y ago
  To unpack that a little, he looks to the writings of the early developers of object oriented programming and identifies the ways this assumption became established. People like Bjarne Stroustrup (developer of C++) took on and promulgated the view that the inheritance hierarchy of classes in an object oriented system can be or should be a literal instantiation of the types of objects from the domain model (e.g. different types of shapes in a drawing program). This is a mistake is because it puts the broad-scale modularization boundaries of a system in the wrong places and makes the system brittle and inflexible. A better approach is one where large scale system boundaries fall along computational capability lines, as exemplified by modern Entity Component Systems. Class hierarchies that rigidly encode domain categorizations don't make for flexible systems. Some of the earliest writers on object encapsulation, e.g. Tony Hoare, Doug Ross, understood this, but later language creators and promoters missed some of the subtleties of their writings and left us with a poor version of object-oriented programming as the accepted default.
  - mariodiana 1y ago
    Is Objective-C discussed at all?
    - tmp10423288442 1y ago
      Only as a brief aside (don't have the timestamp right now) to talking about Smalltalk, which he mostly discusses to argue that Smalltalk was not different from C++ in seeking (most of the time) to model programs in terms of static hierarchies (according to the primary source documentation from the time of Smalltalk's design): > And another thing is if you look at the other branch, > the branch that I'm not really covering very much > in this talk, because again, > we don't program in small talk these days, right? > The closest thing you would get > is maybe something like Objective-C. > If there's some people out there using Objective-C, > you know, like Apple was using that for a little while, > so Objective-C kind of came > from a small talk background as well. Objective-C is basically Smalltalk retrofitted onto C, even more than C++ was Simula retrofitted onto C (before C++ gained template metaprogramming and more modern paradigms), so it makes sense that Muratori doesn't go much into it, given that he doesn't discuss Smalltalk much.

lproven 1y ago

Is there a script or transcript anywhere, for those of us who can read 10x faster than it is possible to understand speech?

cma 1y ago
About every video on YouTube has a transcript, usually a button at the bottom of the description.
- lproven 1y ago
  No help. It's video speed. I can read at several thousand words a minute. So I need the whole transcript in one shot. Then I can read it in 10 or 15 minutes or so, and decide if it's worth watching a 2 hour plus video. The answer is almost always "no".
  - veggieroll 1y ago
    Use yt-dlp to download the transcript.
  - zahlman 1y ago
    A few lines of Javascript in the console can copy that to the clipboard for you. Maybe someone's packaged that up already. (It's on my todo list to look around...)
    - insin 1y ago
      Control Panel for YouTube [1] has an option to add a new "Download" item to the menu in the video Transcript box (which I've just noticed is currently broken, as YouTube must have changed the implementation again recently) Here's a fixed version [2] - run this when the transcript is open and loaded. [1] https://soitis.dev/control-panel-for-youtube https://soitis.dev/control-panel-for-youtube [2] https://gist.github.com/insin/cb938324866c511066bcabe230b6a625 https://gist.github.com/insin/cb938324866c511066bcabe230b6a6...
  - cma 1y ago

masfoobar 1y ago

I enjoyed listening to this talk. In many ways I was aware of the history of OOP but its great to see it in more detail with quotes from known names, etc. I also appreciate the shoutout to Looking Glass Studios and their Thief: the dark project game. I LOVED this game when it came out. Obviously the programmer inside appreciates Thief for its overall design as well. Around 2005 I had to make a graphical shop floor on the web and all product on shelves, etc. Trying to do this in HTML4 with different browsers was a pain, and mostly written in Javascript. During my later time in the project I started to get a feel for AJAX and I wanted to move all my javascript into a library (backend) so I could do more than just an HTML interface. I was thinking OpenGL and other methods or even networking where multiple people could do things together. I started re-writing a VB.NET version of this javascript library and I could not get past the initial design. Remember i'm technically still a junior developer. I was designing the project "the right way" with OOP - inheritence, overrides, etc. It "looked nice" when you view my OOP as a diagram. It starts off well but when you go down the rabbit hole as well as new features it starts to get bloated and messy. In the end I thought about games I was writing in C and viewed what I was doing in a game-like way. I ended up creating each "item" with a unique Id (index) and a bunch of "features" that link to the "item" Id. This way, when rendering, I just look each "feature" update and re-render. It was working suprisingly well. I could then, for each customer using this product, could have their own XML file to store each "object" which was simply an "item" with "features" Obviously, this is all before I had heard of Entity Component Systems (ECS) or Data-oriented Design, and other names. I still treasure that project to this very day as a pure success story. I was porting it over to C# before I decided to leave around 2009. If the pay was better, I could still be working for them today (assuming I get more pay increase as the years passed) It is a reminder that OOP is not be-all-end-all solution.

medmedsalem 1y ago

[flagged]

kristianp 1y ago

And on the other end of the spectrum, you have the proponents of Domain-driven design (DDD)[0], where they use an ML descended language such as F# and the aim is to make invalid states unrepresentable by the program [1] [0] https://fsharpforfunandprofit.com/ddd/ https://fsharpforfunandprofit.com/ddd/ [1] Make invalid states unrepresentable: https://geeklaunch.io/blog/make-invalid-states-unrepresentable/ https://geeklaunch.io/blog/make-invalid-states-unrepresentab...

zero_shift 1y ago
There is a good book on DDD in F#, Domain Modelling Made Functional
- clickety_clack 1y ago
  Yes! I just got a copy of this a couple of days ago. Ive been on a DDD + FP kick recently and it’s leading to some really satisfying solutions.
- HexDecOctBin 1y ago
  Is there a similar recommended book using ML/OCaml or some other language of the family? i am hesitant to learn F#, knowing Microsoft's tendencies.
  - S04dKHzrKT 1y ago
    There are very few F# specific features used in the book. I imagine you could follow along pretty easily with any other functional language. You can easily use F# for the book and then apply the lessons learned to another language when you're done too. It mainly shows how to use sum types, product types and function composition to implement DDD. I'm not sure what tendencies you're referring to though. F# has been around for 20 years and has only gotten better over time.
zozbot234 1y ago
How is this "the other end of the spectrum"? The Typestate pattern described at https://geeklaunch.io/blog/make-invalid-states-unrepresentable/#state-machines-and-state-transitions 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.

deleted 1y ago

[deleted]

cloogshicer 1y ago

Can someone point to a real life example or tutorial/guide of the ECS architecture he proposes? I'd like to learn more about how to implement this.

adastra22 1y ago
Like this? https://devlog.hexops.com/2022/lets-build-ecs-part-1/ https://devlog.hexops.com/2022/lets-build-ecs-part-1/
joeblubaugh 1y ago
They’re very common in video game programming and visual effects and uncommon elsewhere. I enjoyed this article, though it’s still about using ECS in a simulation / computer graphics context. https://adventures.michaelfbryan.com/posts/ecs-outside-of-games/ https://adventures.michaelfbryan.com/posts/ecs-outside-of-ga...
jayd16 1y ago
The two biggest for-sale engines have their implementations as well as what others have posted. Unity ECS (has a pretty good general introduction to ECS) https://docs.unity3d.com/Packages/com.unity.entities@1.3/manual/concepts-ecs.html https://docs.unity3d.com/Packages/com.unity.entities@1.3/man... Unreal https://dev.epicgames.com/documentation/en-us/unreal-engine/overview-of-mass-entity-in-unreal-engine https://dev.epicgames.com/documentation/en-us/unreal-engine/...
crabmusket 1y ago
Here's something that I think is in the direction Casey advocates for without being full-blown ECS: https://gamedev.net/blogs/entry/2265481-oop-is-dead-long-live-oop/ https://gamedev.net/blogs/entry/2265481-oop-is-dead-long-liv... As I posted on the video itself: https://news.ycombinator.com/item?id=44611240 https://news.ycombinator.com/item?id=44611240
dkbrk 1y ago
It's a bit of a long read, but I think the best introduction is still this [0] and the comments were here [1]. Yes, it's presented in the context of rust and gamedev, but ECS isn't actually specific to a particular programming language or problem domain. [0]: https://kyren.github.io/2018/09/14/rustconf-talk.html https://kyren.github.io/2018/09/14/rustconf-talk.html [1]: https://news.ycombinator.com/item?id=17994464 https://news.ycombinator.com/item?id=17994464

chrisg23 1y ago

This is an excellent talk. It digs really deep into the history of OOP, from 1963 to 1998. The point is that in 1998 the commercial game "Thief" was developed using an entity component system (ECS) architecture and not regular OOP. This is the earliest example he knows of in modern commercial programming. During his research into the history of OOP he discovered that ECS existed as early as 1963, but was largely forgotten and not brought over as a software design concept or methodology when OOP was making its way into new languages and being taught to future programmers. There's lots of reasons for why this happened, and his long talk is going over the history and the key people and coming up with an explanatory narrative.

lemonberry 1y ago
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.
inopinatus 1y ago
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.
pjmlp 1y ago
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.
- zaphar 1y ago
  I am not sure what the link between ECS and protocols, traits, and multiple inheritance is? ECS is mostly about memory layout not typed interfaces as far as I know.

MantisShrimp90 1y ago

i love casey and I love this talk. Always good to see people outside of academia doing deep research and this corroborates allot of how I have understood the subject. I find it funny that even after he goes into explicit detail about describing oop back to the original sources people either didn't watch it or are just blowing past his research to move the goal post and claim thats not actually what OOP is because they don't want to admit the industry is obsessed with a mistake just like waterfall and are too stockholm syndromed to realize

zaphar 1y ago
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.
- mrkeen 1y ago
  The problem is when you take out mistakes, there's not much left of OOP. We take out 'dog-is-an-animal' inheritance. We take out object-based delegation of responsibility (an object shall know how to draw itself). A Painter will instead draw many fat structs. Code reuse? Per the talk, the guy who stumbled onto this was really looking for a List<> use-case, (not a special kind of Bus/LinkedList hybrid. He was after parametric polymorphism, not inheritance.
- vkazanov 1y ago
  The problem is that once you exclude domain-specific hierarchy from the discussion, there's not much left of OOP. It's just data + relevant functions. Which is ok. That's all there is, really.
  - mrkeen 1y ago
    And Rich Hickey calls out even that last feature as a mistake, and I tend to agree. https://gist.github.com/reborg/dc8b0c96c397a56668905e2767fd697f#should-i-use-a-namespace-to-bundle-functions-to-model-a-domain-object-like-a-customer-or-product https://gist.github.com/reborg/dc8b0c96c397a56668905e2767fd6...

voidhorse 1y ago

As someone who has always found popular OOP stupid (programming is closer to math, not linguistics—write functional programs!) I'm glad Casey is going out there and giving talks like this. If extensive academic research and extensively documented benefits couldn't convince the industry to abandon OOP in favor of functional style maybe an everyman like Casey finally can. A lot of so-called programmers and systems "engineers" act like religious zealots. Even challenging the ideas of OOP is blasphemy to them, even though there are many legitimate reasons to do so.

vjvjvjvjghv 1y ago
I was around when OOP became popular in the 90s. I think it was a huge step forward. Problem is that with almost every useful paradigm at some point consultants and zealots take over and push things to an extreme that doesn't work. And when problems show up, it's because you didn't do it right. Happened with OOP, NoSQL, Agile and probably many others. I don't see how functional style won't go differently.
- lisbbb 1y ago
  Despite spending untold hours learning and using C++ and Java, I never fully believed that OOP was anything great. It always felt so forced to code everything in terms of classes rather than just modules of code that have similar responsibilities.
  - Jtsummers 1y ago
    You must not mean C++ when you write about having to write everything in terms of classes. Java, yes, with the requirement that the nearest thing to a free standing function is a static method in a class (which becomes in effect a regular old module). But C++? You could, and many did, pretend it was fancy C and only deal with classes when it came to using things like collections and streams (because they were useful).
  - vjvjvjvjghv 1y ago
    The whole code everything in classes idea came up when the purists took over. I (and most reasonable people I know) wrote most of their code in single functions and used instantiable classes only where it made sense. A class with only static methods is basically a module.

DavidPiper 1y ago

So much gold to mine in this talk. Even just this kind of throwaway line buried deep in the Q&A: > I prefer to write code in a verb-oriented way not an object-oriented way. ... It also has to do with what type of system you're making: whether people are going to be adding types to the system more frequently or whether they're going to be adding actions. I tend to find that people add actions more frequently. Suddenly clicked for me why some people/languages prefer doThing(X, Y) vs. X.doThing(Y)

BoiledCabbage 1y ago
More info on "The Expression Problem" https://en.wikipedia.org/wiki/Expression_problem https://en.wikipedia.org/wiki/Expression_problem
pjmlp 1y ago
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.
- virgilp 1y ago
  There are a handful of (somewhat exotic) languages that support multiple dispatch - pretty much, all those listed by you. None of the mainstream ones (C++, Java, C# etc) do. (also Common Lisp is hardly a poster child of OOP, at best you can say it's multi-paradigm like Scala)
  - pjmlp 1y ago
    I guess Julia and Clojure are exotic. Since when do OOP languages have to be single paradigm? By then point of view, people should stop complaining about C++ OOP then.
    - virgilp 1y ago
      > Since when do OOP languages have to be single paradigm? What I really meant to say with that was that it's lisp at its core -i.e. if one wants to place it squarely in one single paradigm, imo that one should be "Functional". I was just surprised to see it listed as an example of OOP language, because it's not the most representative one at that.

lisbbb 1y ago

I complained a lot about OOP all throughout my 25 years a developer. I wrote a ton of C++ and then Java and nobody can refute my expertise with those languages. I saw so many people make mistakes using them, particularly with forcing taxonomies into situations that weren't conducive to having them. Then, when I began complaining to my colleagues about my feelings, I was ostracized and accused of "not having a strong enough skillset." In other words, the dogma of the time overrode the Cassandras saying that the emperor had no clothes. Meanwhile, the simple nature of C and even scripting languages was considered out date. The software dev community finally realized how bad things had gotten with Java and then the walls came a tumbling down. I far prefer writing non-OO Python (or minimal use of classes) to anything else these days. I went all around the language world--did projects involving Lua, Clojure, tons of Groovy, then moved on to Functional Java, Kotlin, and Golang.

hackthemack 1y ago
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.
gloomyday 1y ago
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.
pjmlp 1y ago
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'] >>>

rr808 1y ago

I really dont understand his reasoning. If you have a pointer to the base class different implementations are polymorphic and its hidden from the caller. That is the whole point and it means you can have an engine with a base class in a library, then different people can derive from it and use that engine. I think his definition of OO is different to what we've got used to. Perhaps his definition needs a different name.

henning 1y ago
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?
constantcrying 1y ago
>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.
- igouy 1y ago
  "The expression problem matrix … In object-oriented languages, it's easy to add new types but difficult to add new operations … Whereas in functional languages, it's easy to add new operations but difficult to add new types" https://eli.thegreenplace.net/2016/the-expression-problem-and-its-solutions/ https://eli.thegreenplace.net/2016/the-expression-problem-an...
- rr808 1y ago
  OK then in his base class he has function pointers to different implementations. How can you compile a base class Shape with C++ in a library that will have derivations you dont know about?

xg15 1y ago

OOP has lots of flaws and is not a good choice in every context, but I still don't understand the universal hatred it seems to get now. I think OOP techniques made most sense in contexts where data was in memory of long-running processes - think of early versions of MS Office or such. We've since changed into a computing environment in which everything that is not written to disk should be assumed emepheral: UIs are web-based and may jump not just between threads or processes but between entire machines between two user actions. Processes should be assumed to be killed and restarted at any time, etc etc. This means it makes a lot less sense today to keep complicated object graphs in memory - the real object graph has to be represented in persistent storage and the logic inside a process works more like a mathematical function, translating back and forth between the front-end representation (HTML, JSON, etc) and the storage representation (flat files, databases, etc). The "business logic" is just a sub-clause in that function. For that kind of environment, it's obvious why functional or C-style imperative programming would be a better fit. It makes no sense to instantiate a complicated object graph from your input, traverse it once, then destroy it again - and all that again and again for every single user interaction. But that doesn't mean that the paradigm suddenly has always been bad. It's just that the environment changed. Also, there may be other contexts in which it still makes sense, such high-level scripting or game programming.

constantcrying 1y ago
Did you spend even 3 Minutes trying to understand what the talk was about?
nickitolas 1y ago
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.

tw061023 1y ago

It seems the community is severely overexposed to bad practices and implementations of OOP and conversely severely underexposed to the success stories. 153 comments as of time of writing, let's see. C-F: Java: 21 C++: 31 Python: 23 C#: 2 And yet: Pascal: 1 (!) Delphi: 0 VCL: 0 Winforms: 0 Ruby: 2 (in one comment) This is not a serious conversation about merits of OOP or lack thereof, just like Casey's presentation is not a serious analysis - just a man venting his personal grudges. I get that, it's completely justified - Java has a culture of horrible overengineering and C++ is, well, C++, the object model is not even the worst part of that mess. But still, it feels like there is a lack of voices of people for whom the concept works well. People can and will write horrible atrocities in any language with any methodologies; there is at least one widely used "modern C++" ECS implementation built with STL for example (which itself speaks volumes), and there is a vast universe of completely unreadable FP-style TypeScript code out there written by people far too consumed by what they can do to stop for a second and think if they should. I don't know why Casey chose this particular hill to die on, and I honestly don't care, but we as a community should at least be curious if there are better ways to do our jobs. Sadly, common sense seems to have given way to dogma these days.

nivertech 1y ago

2.5 hours to explain [a concept somewhat similar to] AoS vs SoA? Unlike the mainstream OOP, ECS (Entity Component System) is a niche programming model, even Erlang/OTP is probably more OOP-like than ECS. Same with Agents. But the Software Archeology part was amazing.