7 ms·

The Big Oops: Anatomy of a Thirty-Five-Year Mistake [video]

192 points by doruk101 1y ago

adamrezich 1y ago
I know a two-and-a-half hour video is a hard sell for most people, but I found this talk to be absolutely fascinating. It's not yet another tired “let's all shit on OOP just for the sake of it”-type thing—instead, it's basically nothing but solid historical information (presented with evidence!) as to how “OOP”, as we now know it, came to be. The specific context in which these various decisions were made is something that nobody ever cares to teach, such that it's basically long-since forgotten today—yet here it is, in an easily-digestible format!
- Jtsummers 1y ago
  Amusingly, an hour into the video he complains about information being hidden behind hours of video. It would be a better paper, but apparently he hasn't written or put one out there. Probably a 20-30 minute read instead of 2.5 hours (or 1.25 since I'm running it at double speed).
  - adamrezich 1y ago
    To be fair, though, the video has an uncommonly high (by modern standards!) information density/signal-to-noise ratio—there's minimal filler, and it's very straightforward and to-the-point with regards to its subject matter!
    - igouy 1y ago
      > minimal filler 13:45 -- "He's like, inheritance was like really powerful, but people just didn't know how to use it. Novices and experts apparently both couldn't use it, right. It was just uh you know, it's really good, but no one can figure out how to use it, I guess. Uh so that's a little bit weird."
  - nickitolas 1y ago
    I don't know if it matters to you, but the "video" is just a recording of a conference talk. It wasn't made with the sole intention of making a "video". I agree a text format version of the same information would be useful.
    - em-bee 1y ago
      same difference? it just translates to "information being hidden behind hours of conference talks"? isn't that arguably even worse? imagine the talk was not recorded, and the only way to learn this is to catch the speaker at a conference and listen to him talk?
    - deleted 1y ago
      [deleted]
SanJacobs 1y ago
Waaait, but I thought OOP was carefully crafted to "scale with big teams", and that's why it works so... ahem... "well". Turns out it was just memetic spillover from the creators' previous work?
- Jtsummers 1y ago
  And we absolutely needed 30-45 minutes to learn that that wasn't why it was created. The first part is a history of OOP languages to debunk something I'd never heard even claimed until I watched this video. The history was interesting, but also wrong in a few places. It was amusing to hear him talk about Arpanet being used in the 90s, though.
  - nickitolas 1y ago
    > but also wrong in a few places Would you be so kind as to elaborate how/where? (Other than the "arpanet in the 90s")
    - Jtsummers 1y ago
      If I get bored with life I'll rewatch and take notes, that was the main one that made me chuckle and stuck with me. It was details around Lisp and a couple other things that were outside his explicit research scope (he specifically researched C++, Smalltalk, and Simula per his blog). Like claiming that everything in Lisp was based on lists (even in 1960 that wasn't true). I'd just expect more from someone who takes 30+ minutes to debunk a claim that doesn't matter and most people have never heard to be more particular in getting details correct. On the first part of the video, to be more constructive, it does not matter why a language or tool or whatever was made. The claim, that he debunks, is that OO languages were made to be good for working with teams. Whether it was made for that is immaterial, and no one needs 30 minutes of mostly historically correct video to get to The Truth(tm) of the matter. What's more interesting, and he never bothered to get into, is whether OO is actually good for working with teams (I can go either way, I've dealt with enough garbage OO programs to know that OO itself does not help things, but enough good OO programs to know that it can help things). To anyone who has not yet watched the video, the second half is interesting, the first half is mostly a waste of time.
MintPaw 1y ago
Great video, I knew like 0.1% of those things before watching.
abetusk 1y ago
I found this talk to be great. It goes through the history of OOP and how some of the ideas for the more modern ECS were embedded in the culture at the formation of OOP in the 1960s to 1980s but somehow weren't adopted. It was pretty clear, even 20 years ago, that OOP had major problems in terms of what Casey Muratori now calls "hierarchical encapsulation" of problems. One thing that really jumped out at me was his quote [0]: > I think when you're designing new things, you should focus on the hardest stuff. ... we can always then take that and scale it down ... but it's almost impossible to take something that solves simple problems and scale it up into something that solves hard [problems] I understand the context but this, in general, is abysmally bad advice. I'm not sure about language design or system architecture but this is almost universally not true for any mathematical or algorithmic pursuit. [0] https://www.youtube.com/watch?v=wo84LFzx5nI&t=8284s https://www.youtube.com/watch?v=wo84LFzx5nI&t=8284s
- dkbrk 1y ago
  > I'm not sure about language design or system architecture but this is almost universally not true for any mathematical or algorithmic pursuit. I don't agree. While starting with the simplest case and expanding out is a valid problem-solving technique, it is also often the case in mathematics that we approach a problem by solving a more general problem and getting our solution as a special case. It's a bit paradoxical, but a problem that be completely intractable if attacked directly can be trivial if approached with a sufficiently powerful abstraction. And our problem-solving abilities grow with our toolbox of ever more powerful and general abstractions. Also, it's a general principle in engineering that the initial design decisions, the underlying assumptions underlying everything, is in itself the least expensive part of the process but have an outsized influence on the entire rest of the project. The civil engineer who halfway through the construction of his bridge discovers there is a flaw in his design is having a very bad day (and likely year). With software things are more flexible, so we can build our solution incrementally from a simpler case and swap bits out as our understanding of the problem changes; but even there, if we discover there is something wrong with our fundamental architectural decisions, with how we model the problem domain, we can't fix it just by rewriting some modules. That's something that can only be fixed by a complete rewrite, possibly even in a different language. So while I don't agree with your absolute statement in general, I think it is especially wrong given the context of language design and system architecture. Those are precisely the kind of areas where it's really important that you consider all the possible things you might want to do, and make sure you're not making some false assumption that will massively screw you over at some later date.
hmry 1y ago
Wow, definitely much more than I expected from the title. Really enjoyed the surprise mini-talk about the origin of entity-component-system in the Q&A section as well.
chapliboy 1y ago
I thought it was very interesting about how Alan Kay and Bjarne Stroustrup may have been applying wisdom from their old fields of expertise and how that affected their philosophy. There is an appeal to building complexity through Emergence, where you design several small self-contained pieces that have rich interactions with each other and through those rich interactions you can accomplish more complex things. Its how the universe seems to work. But I also think that the kinds of tools that we have make designing things like this largely impossible. Emergence tends to result in things that we dont expect, and for precise computation and engineering, it feels like we are not close to accomplishing this. So the idea that we need a sense of 'omniscience' for designing programs on individual systems feels like it is the right way to go.
- Fellshard 1y ago
  The universe may work this way, but we're not God, and modes of computation that work like this still inevitably be impossible for us to predict or comprehend. This may be interesting if you're trying to run simulations (remember the point about SIMULA?) but it's not something you could use to accomplish specific ends, I expect.
- sebastos 1y ago
  Another angle I was thinking about, re the need for omniscience: Physical systems seem compelled to play by these object oriented rules, where encapsulation is the norm, and information must be transmitted, and locality dominates. But if we are to try to emulate that ethos in our computer programs, one thing the OOP paradigm seems to glaze over is that you aren’t allowed to _only_ write the ‘atoms’ of that universe - we also have to write the ‘laws of physics’ themselves (if you follow the analogy). And what is more global and all-touching than the laws of physics? So if you look at it through that lens, the need for a little omniscience seems natural. The mistake was in thinking that the program was identified with the objects that the laws govern, when really you have to cover those AND the laws themselves.
usefulcat 1y ago
I'm quite interested in this talk. Haven't finished yet, just watched the first part last night. But I gotta say, I find the graphical background (the blurry text around the edge of the screen that's constantly moving and changing) supremely annoying, not to mention completely unnecessary. Dear presenters and conference producers: please, please don't do that.
- eviks 1y ago
  Yes, visual noise is bad and an attention hijack. Zooming in helps a bit, though precise zooming isn't always available...
cma 1y ago
One thing between 1960s Sutherland and 1990s Looking Glass he left out I think was column-oriented databases (70s and 80s). That might have been important for the performance aspects that drove the resurgence in ECS, though I know he's focused more in this talk on how ECS also improves the structure for understanding and implementing complex systems: in the 70s and early 80s memory latency probably hadn't begun diverging from instruction rate to such an extreme degree, but in disks it was always a big issue. Also would like to hear more about Thinglab and if it had some good stuff to it.
- igouy 1y ago
  more about Thinglab https://archive.esug.org/HistoricalDocuments/ThingLab/ThingLab-Chapter_1.html https://archive.esug.org/HistoricalDocuments/ThingLab/ThingL...
romaniv 1y ago
This video contains many serious misrepresentations. For example, it makes a claim that Alan Kay only started talking about message-passing only in 2003 and that it was a kind of backpedaling due the failures of the inheritance-based OOP model. That is a laughable claim. Kay had given detailed talks discussing issues of OOP, dynamic composition and message-passing in mid-80s. Some of those talks are on YouTube: https://www.youtube.com/watch?v=QjJaFG63Hlo https://www.youtube.com/watch?v=QjJaFG63Hlo Also, earlier versions of Smalltalk did not have inheritance. Kay talks about this is his 1993 article on the history of the language: https://worrydream.com/EarlyHistoryOfSmalltalk/ https://worrydream.com/EarlyHistoryOfSmalltalk/ Dismissing all of this as insignificant quips is ludicrous.
- Mathnerd314 1y ago
  The dates are the dates of the sources, he says in the talk he wasn't going to try to infer the dates these ideas were invented. Also he barely talked about Alan Kay.
  - romaniv 1y ago
    From the video: "It's like, yeah, he said that in 2003, right? He said that after a very long time. So why did he say it? It's because 10 years earlier, he was already saying he kind of soured on it." https://youtu.be/wo84LFzx5nI?t=823 https://youtu.be/wo84LFzx5nI?t=823 He mentions Alan Kay about dozen times and uses quotes and dates to create a specific narrative about Smalltalk. That narrative is demonstrably false.
    - Mathnerd314 1y ago
      Casey says he “didn’t really cover Alan Kay” https://youtu.be/wo84LFzx5nI?t=8651 https://youtu.be/wo84LFzx5nI?t=8651 To me that says that Kay wasn’t a major focus of his research. That seems to be reflected in the talk itself: I counted 6 Bjorne sources, 4 Alan Kay sources, 2 more related to Smalltalk, and about 10 focused on Sketchpad, Douglas Ross, and others. By source count, the talk is roughly 18% about Alan Kay and 27% about Smalltalk overall - not a huge part. As far as the narrative, probably the clearest expression of Casey's thesis is at https://youtu.be/wo84LFzx5nI?t=6187 https://youtu.be/wo84LFzx5nI?t=6187 "Alan Kay had a degree in molecular biology. ... [he was] thinking of little tiny cells that communicate back and forth but which do not reach across into each other's domain to do different things. And so [he was certain that] that was the future of how we will engineer things. They're going to be like microorganisms where they're little things that we instance, and they'll just talk to each other. So everything will be built that way from the ground up." AFAICT the gist of this is true, Kay was indeed inspired by biological cells and that is why he emphasized message-passing so heavily. His undergraduate degree was in math + bio, not just bio, but close enough. As far as specific discussion, Casey says, regarding a quote on inheritance: https://youtu.be/wo84LFzx5nI?t=843 https://youtu.be/wo84LFzx5nI?t=843 "that's a little bit weird. I don't know. Maybe Alan Kay... will come to tell us what he actually was trying to say there exactly." So yeah, Casey has already admitted he has no understanding of Alan Kay's writings. I don't know what else you want.
zozbot234 1y ago
A "compile-time hierarchy of encapsulation that matches the domain model"? Don't we all call that Typestate these days? Change my mind: Typestate - and Generic Typestate even more so - is just good old OOP wearing a trenchcoat.
igouy 1y ago
There is a transcript: click Casey's links more click Show transcript
- lproven 1y ago
  I think you mean the machine-generated one on Youtube? It took me a few minutes of searching from your slightly scant description. Is there any way to extract just that text into a document I can read?
  - igouy 1y ago
    None that I can find. Maybe we need to beg the presenter.
    - lproven 1y ago
      I asked him on Twitter. The answer was a simple "sorry, no." Video talks are like LLM bot content, for me: If it wasn't worth writing down, it's not worth my time to watch it.
      - igouy 1y ago
        Maybe it's all about ad-revenue.
        lproven 1y ago
        I agree. And that for me makes me not want to watch. If someone has a message they want to communicate, then it's worth writing down. If they don't, and primarily just want the views, then it's not worth my time.
        Hikikomori 1y ago
        If I was the presenter and reading those comments I would just not make any text post available just out of spite. Jesus people are entitled.
crabmusket 1y ago
I had no idea Thief, one of my favourite games, was built with an ECS-like architecture. Two articles with more interesting details about Thief (I especially love its "temporal" CSG world model): https://nothings.org/gamedev/thief_rendering.html https://nothings.org/gamedev/thief_rendering.html https://www.gamedeveloper.com/design/postmortem-i-thief-the-dark-project-i- https://www.gamedeveloper.com/design/postmortem-i-thief-the-... I skipped a fair chunk of the middle of this video as I really wanted to get to the Sketchpad discussion, which I found very valuable (starting around 1:10). I think Casey was fairly balanced, and emphasized near the end of the talk that some of the things under the OOP umbrella aren't necessarily bad, just overused. For example, actors communicating with message passing could be a great way to model distributed systems. Just not, maybe, a game or editor. Along similar lines, I love this old post "reconstructing" OOP ideas with a much simpler take similar to what Casey advocates for: https://gamedev.net/blogs/entry/2265481-oop-is-dead-long-live-oop/ https://gamedev.net/blogs/entry/2265481-oop-is-dead-long-liv... But I of course enjoyed him calling out the absolutely dire state of OOP education/tutorials. I satirized this on my own blog ages ago: https://crabmusket.net/how-i-learned-oop/ https://crabmusket.net/how-i-learned-oop/ In that post I referenced Sandi Metz as an antidote to awful OOP education. I may just have to include Casey as well.
_zagj 1y ago
For those unaware, Casey Muratori started a project called Handmade Hero in 2014 to build a complete game from scratch while livestreaming the entire process, with the goal of showing people not just how, but why, rolling your own engine (hence the "handmade" part) is better than relying on Unity, Unreal, or some other leaky abstraction. He even solicited pre-orders for the finished product, IIRC. Ten years later, he has no game, only a rudimentary, tile-based dungeon-crawler engine, and reams of code he's written and re-written (as API sands shifted beneath his feet), and the project seems to be permanently on hiatus now. Thus, Casey inadvertently proved himself wrong, and the conventional wisdom (use an existing engine) correct. As far as OOP goes, 45 years has shown that it makes developers highly productive, and ultimately, as the saying goes, "real heroes (handmade or otherwise) ship." Casey's company was founded 20 years ago, and he's never shipped a software product. He complains often about software getting slower, which I agree with. Yet how many mainstays of Windows 95/98 desktop software were written in a significantly OO style using C++ with MFC?
- krapp 1y ago
  I can see the argument for using a custom engine if you have specific design goals that can't be met by existing engines, but that seems seems like an edge case. I think 99% of game concepts can probably be done in Unity, Godot, or Unreal. Meanwhile you could probably surpass Handmade Hero with any off the shelf engine with a tutorial and a few hours' work, or even a project template from an asset store. The biggest problem I have with Handmade Hero is that because Casey is putting so much effort into the coding and architecture up front, the game itself isn't interesting. It's supposed to be a "AAA game" but it's little more than a tech demo. And that's why you use off the shelf engines - they allow you to put effort into designing the game rather than reinventing the wheel.
  - alexvitkov 1y ago
    > 99% of game concepts can probably be done in Unity, Godot, or Unreal. The vast majority of developers use these engines, so you would expect the vast majority of games to be stuff that's easy to make within those engines. With how samey new games are, it's hard to argue that what we see comes close to the full design space of possible interesting games. That's partially developers copying games they've seen work and sell, but it's also developers making what is reasonably easy to make within Unity or Unreal with the resources they have.
ozgrakkurt 1y ago
Well researched, a lot of effort put into it and well presented. Thought he was just producing filler content on youtube but this really shows how magical it can be to put real effort into something.
swyx 1y ago
i'm very curious on how this conference came together. how does a small town in sweden by relative unknowns gather big names like this? is it tied to some elite community that only insiders know?
Sirjazzfeet 1y ago
Great talk, it reminds me when Bob Ross reflected on his career as one big mistake.

192 points by doruk101 1y ago

I know a two-and-a-half hour video is a hard sell for most people, but I found this talk to be absolutely fascinating. It's not yet another tired “let's all shit on OOP just for the sake of it”-type thing—instead, it's basically nothing but solid historical information (presented with evidence!) as to how “OOP”, as we now know it, came to be. The specific context in which these various decisions were made is something that nobody ever cares to teach, such that it's basically long-since forgotten today—yet here it is, in an easily-digestible format!

Jtsummers 1y ago
Amusingly, an hour into the video he complains about information being hidden behind hours of video. It would be a better paper, but apparently he hasn't written or put one out there. Probably a 20-30 minute read instead of 2.5 hours (or 1.25 since I'm running it at double speed).
- adamrezich 1y ago
  To be fair, though, the video has an uncommonly high (by modern standards!) information density/signal-to-noise ratio—there's minimal filler, and it's very straightforward and to-the-point with regards to its subject matter!
  - igouy 1y ago
    > minimal filler 13:45 -- "He's like, inheritance was like really powerful, but people just didn't know how to use it. Novices and experts apparently both couldn't use it, right. It was just uh you know, it's really good, but no one can figure out how to use it, I guess. Uh so that's a little bit weird."
- nickitolas 1y ago
  I don't know if it matters to you, but the "video" is just a recording of a conference talk. It wasn't made with the sole intention of making a "video". I agree a text format version of the same information would be useful.
  - em-bee 1y ago
    same difference? it just translates to "information being hidden behind hours of conference talks"? isn't that arguably even worse? imagine the talk was not recorded, and the only way to learn this is to catch the speaker at a conference and listen to him talk?
  - deleted 1y ago
    [deleted]

SanJacobs 1y ago

Waaait, but I thought OOP was carefully crafted to "scale with big teams", and that's why it works so... ahem... "well". Turns out it was just memetic spillover from the creators' previous work?

Jtsummers 1y ago
And we absolutely needed 30-45 minutes to learn that that wasn't why it was created. The first part is a history of OOP languages to debunk something I'd never heard even claimed until I watched this video. The history was interesting, but also wrong in a few places. It was amusing to hear him talk about Arpanet being used in the 90s, though.
- nickitolas 1y ago
  > but also wrong in a few places Would you be so kind as to elaborate how/where? (Other than the "arpanet in the 90s")
  - Jtsummers 1y ago
    If I get bored with life I'll rewatch and take notes, that was the main one that made me chuckle and stuck with me. It was details around Lisp and a couple other things that were outside his explicit research scope (he specifically researched C++, Smalltalk, and Simula per his blog). Like claiming that everything in Lisp was based on lists (even in 1960 that wasn't true). I'd just expect more from someone who takes 30+ minutes to debunk a claim that doesn't matter and most people have never heard to be more particular in getting details correct. On the first part of the video, to be more constructive, it does not matter why a language or tool or whatever was made. The claim, that he debunks, is that OO languages were made to be good for working with teams. Whether it was made for that is immaterial, and no one needs 30 minutes of mostly historically correct video to get to The Truth(tm) of the matter. What's more interesting, and he never bothered to get into, is whether OO is actually good for working with teams (I can go either way, I've dealt with enough garbage OO programs to know that OO itself does not help things, but enough good OO programs to know that it can help things). To anyone who has not yet watched the video, the second half is interesting, the first half is mostly a waste of time.

MintPaw 1y ago

Great video, I knew like 0.1% of those things before watching.

abetusk 1y ago

I found this talk to be great. It goes through the history of OOP and how some of the ideas for the more modern ECS were embedded in the culture at the formation of OOP in the 1960s to 1980s but somehow weren't adopted. It was pretty clear, even 20 years ago, that OOP had major problems in terms of what Casey Muratori now calls "hierarchical encapsulation" of problems. One thing that really jumped out at me was his quote [0]: > I think when you're designing new things, you should focus on the hardest stuff. ... we can always then take that and scale it down ... but it's almost impossible to take something that solves simple problems and scale it up into something that solves hard [problems] I understand the context but this, in general, is abysmally bad advice. I'm not sure about language design or system architecture but this is almost universally not true for any mathematical or algorithmic pursuit. [0] https://www.youtube.com/watch?v=wo84LFzx5nI&t=8284s https://www.youtube.com/watch?v=wo84LFzx5nI&t=8284s

dkbrk 1y ago
> I'm not sure about language design or system architecture but this is almost universally not true for any mathematical or algorithmic pursuit. I don't agree. While starting with the simplest case and expanding out is a valid problem-solving technique, it is also often the case in mathematics that we approach a problem by solving a more general problem and getting our solution as a special case. It's a bit paradoxical, but a problem that be completely intractable if attacked directly can be trivial if approached with a sufficiently powerful abstraction. And our problem-solving abilities grow with our toolbox of ever more powerful and general abstractions. Also, it's a general principle in engineering that the initial design decisions, the underlying assumptions underlying everything, is in itself the least expensive part of the process but have an outsized influence on the entire rest of the project. The civil engineer who halfway through the construction of his bridge discovers there is a flaw in his design is having a very bad day (and likely year). With software things are more flexible, so we can build our solution incrementally from a simpler case and swap bits out as our understanding of the problem changes; but even there, if we discover there is something wrong with our fundamental architectural decisions, with how we model the problem domain, we can't fix it just by rewriting some modules. That's something that can only be fixed by a complete rewrite, possibly even in a different language. So while I don't agree with your absolute statement in general, I think it is especially wrong given the context of language design and system architecture. Those are precisely the kind of areas where it's really important that you consider all the possible things you might want to do, and make sure you're not making some false assumption that will massively screw you over at some later date.

hmry 1y ago

Wow, definitely much more than I expected from the title. Really enjoyed the surprise mini-talk about the origin of entity-component-system in the Q&A section as well.

chapliboy 1y ago

I thought it was very interesting about how Alan Kay and Bjarne Stroustrup may have been applying wisdom from their old fields of expertise and how that affected their philosophy. There is an appeal to building complexity through Emergence, where you design several small self-contained pieces that have rich interactions with each other and through those rich interactions you can accomplish more complex things. Its how the universe seems to work. But I also think that the kinds of tools that we have make designing things like this largely impossible. Emergence tends to result in things that we dont expect, and for precise computation and engineering, it feels like we are not close to accomplishing this. So the idea that we need a sense of 'omniscience' for designing programs on individual systems feels like it is the right way to go.

Fellshard 1y ago
The universe may work this way, but we're not God, and modes of computation that work like this still inevitably be impossible for us to predict or comprehend. This may be interesting if you're trying to run simulations (remember the point about SIMULA?) but it's not something you could use to accomplish specific ends, I expect.
sebastos 1y ago
Another angle I was thinking about, re the need for omniscience: Physical systems seem compelled to play by these object oriented rules, where encapsulation is the norm, and information must be transmitted, and locality dominates. But if we are to try to emulate that ethos in our computer programs, one thing the OOP paradigm seems to glaze over is that you aren’t allowed to _only_ write the ‘atoms’ of that universe - we also have to write the ‘laws of physics’ themselves (if you follow the analogy). And what is more global and all-touching than the laws of physics? So if you look at it through that lens, the need for a little omniscience seems natural. The mistake was in thinking that the program was identified with the objects that the laws govern, when really you have to cover those AND the laws themselves.

usefulcat 1y ago

I'm quite interested in this talk. Haven't finished yet, just watched the first part last night. But I gotta say, I find the graphical background (the blurry text around the edge of the screen that's constantly moving and changing) supremely annoying, not to mention completely unnecessary. Dear presenters and conference producers: please, please don't do that.

eviks 1y ago
Yes, visual noise is bad and an attention hijack. Zooming in helps a bit, though precise zooming isn't always available...

cma 1y ago

One thing between 1960s Sutherland and 1990s Looking Glass he left out I think was column-oriented databases (70s and 80s). That might have been important for the performance aspects that drove the resurgence in ECS, though I know he's focused more in this talk on how ECS also improves the structure for understanding and implementing complex systems: in the 70s and early 80s memory latency probably hadn't begun diverging from instruction rate to such an extreme degree, but in disks it was always a big issue. Also would like to hear more about Thinglab and if it had some good stuff to it.

igouy 1y ago
more about Thinglab https://archive.esug.org/HistoricalDocuments/ThingLab/ThingLab-Chapter_1.html https://archive.esug.org/HistoricalDocuments/ThingLab/ThingL...

romaniv 1y ago

This video contains many serious misrepresentations. For example, it makes a claim that Alan Kay only started talking about message-passing only in 2003 and that it was a kind of backpedaling due the failures of the inheritance-based OOP model. That is a laughable claim. Kay had given detailed talks discussing issues of OOP, dynamic composition and message-passing in mid-80s. Some of those talks are on YouTube: https://www.youtube.com/watch?v=QjJaFG63Hlo https://www.youtube.com/watch?v=QjJaFG63Hlo Also, earlier versions of Smalltalk did not have inheritance. Kay talks about this is his 1993 article on the history of the language: https://worrydream.com/EarlyHistoryOfSmalltalk/ https://worrydream.com/EarlyHistoryOfSmalltalk/ Dismissing all of this as insignificant quips is ludicrous.

Mathnerd314 1y ago
The dates are the dates of the sources, he says in the talk he wasn't going to try to infer the dates these ideas were invented. Also he barely talked about Alan Kay.
- romaniv 1y ago
  From the video: "It's like, yeah, he said that in 2003, right? He said that after a very long time. So why did he say it? It's because 10 years earlier, he was already saying he kind of soured on it." https://youtu.be/wo84LFzx5nI?t=823 https://youtu.be/wo84LFzx5nI?t=823 He mentions Alan Kay about dozen times and uses quotes and dates to create a specific narrative about Smalltalk. That narrative is demonstrably false.
  - Mathnerd314 1y ago
    Casey says he “didn’t really cover Alan Kay” https://youtu.be/wo84LFzx5nI?t=8651 https://youtu.be/wo84LFzx5nI?t=8651 To me that says that Kay wasn’t a major focus of his research. That seems to be reflected in the talk itself: I counted 6 Bjorne sources, 4 Alan Kay sources, 2 more related to Smalltalk, and about 10 focused on Sketchpad, Douglas Ross, and others. By source count, the talk is roughly 18% about Alan Kay and 27% about Smalltalk overall - not a huge part. As far as the narrative, probably the clearest expression of Casey's thesis is at https://youtu.be/wo84LFzx5nI?t=6187 https://youtu.be/wo84LFzx5nI?t=6187 "Alan Kay had a degree in molecular biology. ... [he was] thinking of little tiny cells that communicate back and forth but which do not reach across into each other's domain to do different things. And so [he was certain that] that was the future of how we will engineer things. They're going to be like microorganisms where they're little things that we instance, and they'll just talk to each other. So everything will be built that way from the ground up." AFAICT the gist of this is true, Kay was indeed inspired by biological cells and that is why he emphasized message-passing so heavily. His undergraduate degree was in math + bio, not just bio, but close enough. As far as specific discussion, Casey says, regarding a quote on inheritance: https://youtu.be/wo84LFzx5nI?t=843 https://youtu.be/wo84LFzx5nI?t=843 "that's a little bit weird. I don't know. Maybe Alan Kay... will come to tell us what he actually was trying to say there exactly." So yeah, Casey has already admitted he has no understanding of Alan Kay's writings. I don't know what else you want.

zozbot234 1y ago

A "compile-time hierarchy of encapsulation that matches the domain model"? Don't we all call that Typestate these days? Change my mind: Typestate - and Generic Typestate even more so - is just good old OOP wearing a trenchcoat.

igouy 1y ago

There is a transcript: click Casey's links more click Show transcript

lproven 1y ago
I think you mean the machine-generated one on Youtube? It took me a few minutes of searching from your slightly scant description. Is there any way to extract just that text into a document I can read?
- igouy 1y ago
  None that I can find. Maybe we need to beg the presenter.
  - lproven 1y ago
    I asked him on Twitter. The answer was a simple "sorry, no." Video talks are like LLM bot content, for me: If it wasn't worth writing down, it's not worth my time to watch it.
    - igouy 1y ago
      Maybe it's all about ad-revenue.
      - lproven 1y ago
        I agree. And that for me makes me not want to watch. If someone has a message they want to communicate, then it's worth writing down. If they don't, and primarily just want the views, then it's not worth my time.
        Hikikomori 1y ago
        If I was the presenter and reading those comments I would just not make any text post available just out of spite. Jesus people are entitled.

crabmusket 1y ago

I had no idea Thief, one of my favourite games, was built with an ECS-like architecture. Two articles with more interesting details about Thief (I especially love its "temporal" CSG world model): https://nothings.org/gamedev/thief_rendering.html https://nothings.org/gamedev/thief_rendering.html https://www.gamedeveloper.com/design/postmortem-i-thief-the-dark-project-i- https://www.gamedeveloper.com/design/postmortem-i-thief-the-... I skipped a fair chunk of the middle of this video as I really wanted to get to the Sketchpad discussion, which I found very valuable (starting around 1:10). I think Casey was fairly balanced, and emphasized near the end of the talk that some of the things under the OOP umbrella aren't necessarily bad, just overused. For example, actors communicating with message passing could be a great way to model distributed systems. Just not, maybe, a game or editor. Along similar lines, I love this old post "reconstructing" OOP ideas with a much simpler take similar to what Casey advocates for: https://gamedev.net/blogs/entry/2265481-oop-is-dead-long-live-oop/ https://gamedev.net/blogs/entry/2265481-oop-is-dead-long-liv... But I of course enjoyed him calling out the absolutely dire state of OOP education/tutorials. I satirized this on my own blog ages ago: https://crabmusket.net/how-i-learned-oop/ https://crabmusket.net/how-i-learned-oop/ In that post I referenced Sandi Metz as an antidote to awful OOP education. I may just have to include Casey as well.

_zagj 1y ago

For those unaware, Casey Muratori started a project called Handmade Hero in 2014 to build a complete game from scratch while livestreaming the entire process, with the goal of showing people not just how, but why, rolling your own engine (hence the "handmade" part) is better than relying on Unity, Unreal, or some other leaky abstraction. He even solicited pre-orders for the finished product, IIRC. Ten years later, he has no game, only a rudimentary, tile-based dungeon-crawler engine, and reams of code he's written and re-written (as API sands shifted beneath his feet), and the project seems to be permanently on hiatus now. Thus, Casey inadvertently proved himself wrong, and the conventional wisdom (use an existing engine) correct. As far as OOP goes, 45 years has shown that it makes developers highly productive, and ultimately, as the saying goes, "real heroes (handmade or otherwise) ship." Casey's company was founded 20 years ago, and he's never shipped a software product. He complains often about software getting slower, which I agree with. Yet how many mainstays of Windows 95/98 desktop software were written in a significantly OO style using C++ with MFC?

krapp 1y ago
I can see the argument for using a custom engine if you have specific design goals that can't be met by existing engines, but that seems seems like an edge case. I think 99% of game concepts can probably be done in Unity, Godot, or Unreal. Meanwhile you could probably surpass Handmade Hero with any off the shelf engine with a tutorial and a few hours' work, or even a project template from an asset store. The biggest problem I have with Handmade Hero is that because Casey is putting so much effort into the coding and architecture up front, the game itself isn't interesting. It's supposed to be a "AAA game" but it's little more than a tech demo. And that's why you use off the shelf engines - they allow you to put effort into designing the game rather than reinventing the wheel.
- alexvitkov 1y ago
  > 99% of game concepts can probably be done in Unity, Godot, or Unreal. The vast majority of developers use these engines, so you would expect the vast majority of games to be stuff that's easy to make within those engines. With how samey new games are, it's hard to argue that what we see comes close to the full design space of possible interesting games. That's partially developers copying games they've seen work and sell, but it's also developers making what is reasonably easy to make within Unity or Unreal with the resources they have.

ozgrakkurt 1y ago

Well researched, a lot of effort put into it and well presented. Thought he was just producing filler content on youtube but this really shows how magical it can be to put real effort into something.

swyx 1y ago

i'm very curious on how this conference came together. how does a small town in sweden by relative unknowns gather big names like this? is it tied to some elite community that only insiders know?

Sirjazzfeet 1y ago

Great talk, it reminds me when Bob Ross reflected on his career as one big mistake.