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,_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.
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.
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
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."
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.
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.
- 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.
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.
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.
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.
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.
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]
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.
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
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.
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)
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.
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.
> 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.
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.
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.
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.
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.
35 comments
[ 3.4 ms ] story [ 58.9 ms ] thread"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
"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."
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
- 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.
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.
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.
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.
[0] https://fsharpforfunandprofit.com/ddd/
[1] Make invalid states unrepresentable: https://geeklaunch.io/blog/make-invalid-states-unrepresentab...
I'd like to learn more about how to implement this.
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.
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
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.
> 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)
https://steve-yegge.blogspot.com/2006/03/execution-in-kingdo...
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 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.
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.
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.
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.