Please join me in welcoming the one, the only, the irreplaceable, Casey Muratori!
 Okay, okay. Way too big, Sam. Sam made it way too big.
 I feel like before we start we should also thank Sam for putting this together.
 It's been a very long time since I've been really excited to give a talk, and a lot of
 that is because the speaker list of this talk is, of this conference is absolutely amazing,
 and I just, I don't know, I'm really excited to be here, and I'm excited to give this talk,
 so I'm just going to jump right into it.
 So I would like to talk about something that happened in 1998 at a company called Looking
 Glass, which normally, like back in the day, contemporaneous with this, if I had said
 Looking Glass, everyone would know who they were, because they were an incredibly influential
 game company that did a lot of firsts in gaming. One of their games, Ultimate Underworld, started
 kind of the 3D revolution in PC gaming, and they were an incredibly innovative company
 at the time. And a lot of people today, I mean, there's people in the audience here
 who weren't even born then, right? So a lot of people today might not know who they were,
 but they're incredibly important. And one of their games was called Thief the Dark Project,
 It's a franchise that lived on, it was one of the first stealth action games, and it
 looks pretty primitive by today's standards, obviously, but this was engine contemporaneous
 with things like Quake, for example, so this was sort of state of the art at the time.
 Now I'm not going to talk about graphics, because I'm not qualified to talk about graphics
 anyway, I'm not a graphics guy.
 What I want to talk about instead is how they modelled entities, and normally the way you
 would do things in games at this time, and in fact the way that Ultima Underworld 1 and
 and then later System Shock was another one of their games.
 The way that they did things was actually the way
 that like me and, for example, Ryan Fleury
 who's gonna be interviewing me after,
 we would say that this is a good way
 to do things even today.
 They were sort of fat structs, if you will.
 They just put everything in one structure
 and when you were going to do things
 like have different types of entities,
 really all you had was some kind of a type field in there
 or flags or things like that that would let you know
 what you were supposed to do with it.
 But these were very, very limited resource times.
 I think the systems, you would expect
 to have something like two megabytes of memory
 or something total to run in.
 So you're talking about fixed blocks of small size
 and everything has to work in that.
 So that's just what you did because that's what worked.
 And in this time frame, right, you know,
 during the 80s and then later 90s when this game was made,
 this is the sort of thing that was in vogue
 in like the architecture world.
 This has nothing to do with how they were doing things
 at Looking Glass.
 This is what we would kind of think of as a normal
 like OOP programming model now,
 where you have a hierarchy of things.
 Like there's an entity class
 and then you have an NPC and item subclass derived from it,
 and then things below that and so on.
 And that was not something that Lookingglass
 had ever really used in that lineage of games
 and their RPGs, and they decided not to go that route
 even though that was sort of what was in vogue at the time.
 That was what was, you would have seen pushed
 if you were reading like architecture things
 in Oops! Law or the kinds of papers
 that would have been published on software architecture.
 So they did something very different.
 What they did is said, look, we want all of our systems
 to be the primary thing that we're going to think about.
 We want to think about physics and combat
 and those sorts of things.
 The same things that were in our Fatty Strux.
 When we do a more serious architecture here,
 we're doing more architectural work,
 we want to put things in terms of their system,
 not in terms of the entity.
 And so what they did is they came up with a system
 where they would use an ID,
 like if I have a particular object
 that I'm trying to model in the world, one of these entities,
 I just have an ID for it.
 And it doesn't really have any data associated with it at all.
 It's kind of the polar opposite of a fat struct.
 So they would just say, we're going
 to use the IDs to represent things.
 And then the way that we form the entity's data
 is we just use that ID to look up into a system
 and say, what's the physics like for this thing?
 What's the combat like for this thing?
 This fuel system I have, I'm just imagining systems
 you might have in a game.
 And in so doing, in 1998, when they shipped Thief,
 Dark Project, they shipped, to the best of my knowledge, the first instance of an actually
 commercially released entity component system. That's what we call it today, right? People
 call it this. This is now an in-vogue architecture in much the way that those hierarchy kinds
 of architectures were in vogue at the time, and still to some extent are today, but not
 necessarily in the game industry. So this is the first time I'm ever aware of anyone
 shipping this kind of model. And in fact, it's the first time I'm aware of anyone even
 talking about this kind of model. I'd never heard of it before. This was the first time.
 And there is a pretty interesting thing that you have to understand about this, and I know
 this may seem like beating a dead horse here, but those red lines that I've drawn there
 are basically encapsulation boundaries. And this is a very important theme throughout
 this talk. I just want to really make sure I hammer it home. Encapsulation boundaries
 are really what we care about when we're doing architecture. What we care about is where
 we make it difficult to access things and where we make it easy, right? And so what
 they chose to do that was very different than that sort of inheritance hierarchy model is
 they chose to draw the encapsulation boundaries around the systems. Now, this is very different
 because the traditional OOP model, right, is you draw the encapsulation boundaries around
 the objects. So the encapsulation boundary in a normal OOP-like hierarchy is I have whatever
 where the object is, like a mech,
 and the encapsulation boundary is around
 all of the things that the mech knows about.
 But that's very different than this.
 This is about all of the things
 that are related to a system,
 not all the things that are related to a mech.
 Now it's important to remember,
 this is not like not-oop.
 You could easily call this object-oriented programming,
 it still obeys a lot of the principles
 you might recognize from object-oriented programming,
 so it's not like they were saying,
 we're getting rid of object-oriented programming.
 They were saying something very different.
 And they were saying, effectively,
 what Mark Blank said, he's the person who actually
 implemented a lot of the system.
 And what he said was, for some reason,
 OOP has gotten into this mindset
 of compile-time hierarchies that match the domain model.
 Meaning, if you think about what you're trying to model
 in the real world, like entities and guards
 and things like this, or even if you're just thinking
 like the natural world, we're gonna think about birds
 and is it a mammal or is it an avian thing, right?
 You're thinking about this domain model
 that you're trying to model in the real world,
 and you're bringing it into the software world.
 And what he was basically saying is like,
 why are we pushing this?
 Why is that the idea, right?
 And he says we can still do OOP style stuff,
 and we can just do it by changing our paradigm
 of what we're thinking about
 in terms of our domain model, right?
 Don't make the domain model be in the code,
 make that be something the user experiences,
 but the code is done in a way
 that makes sense for the code.
 So this is really brilliant,
 and it's a great way to summarize it.
 It's one of my favorite crystallizations of that concept.
 So I would only add one thing to it,
 and that's that word encapsulation.
 Because I think sometimes people think hierarchy,
 they just think the relationships.
 But it's the encapsulation that's really important
 because that's what really determines
 whether or not the code is easy to write or hard to write.
 It's are those boundaries in the right place?
 So this is crucial.
 And this talk is kind of about mistakes, as you'll see.
 And I made a mistake one time.
 I went on this thing, you may have seen it,
 it's called the internet.
 It's like this series of tubes
 that connects people around the world,
 and it's kind of complicated,
 I'm not 100% sure how it works,
 but they have a thing on it called social media
 where what you can do is there's like a box,
 and you can type anything you want into the box.
 It doesn't have to be correct,
 it doesn't have to be coherent,
 it certainly doesn't have to be polite.
 And then you have to push this button,
 there's usually a button next to it,
 but the button says different things sometimes.
 You push the button,
 and everyone in the world has to read it.
 Like, everybody.
 And that's an amazing invention.
 And I was probably doing something like that at the time when I saw some people talking,
 having a discussion about this sort of thing, discussion in quotes, let's say.
 And they were thinking about this.
 They were thinking about, you know, we have old things that were maybe not quite architecture
 like those things, and at some point people started saying, you know, there's
 this other architecture we could do, which is this hierarchy thing, and that's much cleaner,
 it's much better organized, it's better architecture, and they started to push this, right?
 And it definitely got adopted.
 It got adopted everywhere.
 And it's a very standard paradigm, even to this day.
 And they were sort of responding to people
 who were saying this is bad,
 that this hierarchical thing is not a good idea,
 the encapsulation boundaries are in the wrong place,
 as I would say.
 And they're saying, okay, there's no way
 that all of these smart people who pushed this stuff
 and who created this, there's no way
 they could possibly be wrong about it, right?
 Like, surely this comes from all kinds of academic studies
 and ways of looking at things,
 and we definitely have great examples
 this working perfectly I'm sure and it all got translated to us and you guys
 just don't understand and you know we don't understand either because we're
 not really sure what we're saying but we're basically saying that someone must
 have known and those people were smart so there you go right so could you
 really be saying all you naysayers that it doesn't make sense it didn't come
 from a logical place and so the short answer to that is absolutely that's what
 we're saying that's 100% where we're saying and the long answer to this is
 is the rest of this talk.
 Welcome to the Better Software Conference,
 the inaugural Better Software Conference.
 This is the big oops,
 which is my sort of attempt to go back
 over 35 years of history
 to
 figure out where we went wrong.
 Like, how did this happen?
 Okay? Now, just get some
 things out of the way first, and this is mostly
 for the people. I don't know where I'm looking. Is there a
 camera out there? That. This is mostly for the people.
 The people in this room are probably already
 already bought in, right?
 Low-level programming, that sort of thing,
 you're probably like, OK, I like where this is going.
 People on the internet, as I said before,
 maybe that was a mistake.
 But they're going to have some issues with this.
 They have some bones to pick.
 So I just want to say first, when
 I say the big oops anatomy of a 35-year mistake,
 I'm not talking about OOP as a whole.
 I'm talking about looking for very specific things in it.
 And because whenever you talk about OOP,
 it's always this thing where people are like, well,
 whatever you're talking about, that's
 not really OOP.
 Like, you're talking about these things,
 you're using the terminology wrong,
 or that's not how I write code.
 It's like, OOP is just a thing where it's like,
 it's how I like to write code.
 And whatever they're thinking at the time,
 that's what OOP is or something.
 And I don't necessarily blame them
 because it's a nebulous term
 and they have their own definition for it.
 I mean, I probably have my own definition for it.
 That's totally fair, right?
 But I just wanna say,
 we're not gonna be dealing with any of that here,
 so I don't wanna hear the whole like,
 you know, I don't know.
 It's sort of like wine, which I got the slide up in here.
 It's like, if you have like a designated origin,
 You're not allowed to call it certain things,
 and it's that kind of feel, right?
 It's not like, it's not actually oop,
 it's sparkling code or something like this,
 you have to use the right term for it.
 So I just want to be clear,
 I'm talking about something very specific,
 and it's the thing that I just said.
 Very, very specific, and I'm not saying oop was a mistake,
 I'm saying this was a mistake.
 The idea that you're going to draw encapsulation boundaries
 around these compile time hierarchies
 that are based off of whatever you're trying to write.
 Now, second thing we want to get clear
 is I don't want to hear any complaints that no one ever
 pushed this model, because I know that's going to happen.
 I'm looking at UI Combinator.
 I know that this is going to be a thread.
 So anticipating that, let's just say
 we have a lot of historical evidence.
 When I was doing the research for this talk,
 I read so many things from the historical record.
 It is so obvious that everyone actually 100% meant
 you should look at the domain model
 and you should code that directly
 in your compiled hierarchy.
 For example, here is literally Bjarne Stroustrup's paper,
 What is Object-Oriented Programming,
 to tell you what it is.
 And he starts off with a shape example
 that I've used before that everyone said,
 well, that's totally ridiculous.
 You're just cherry picking out of an introductory book.
 This is where he was trying to explain this and sell this
 to people in his industry who were experts.
 And he says, look, if we're going
 to write something like this that has kind k as an enumerant
 there of what the kinds of shapes are, right?
 If we're going to write something like this,
 we end up with code that has a switch statement in it.
 So when we want to draw something,
 we have to say, oh, what is this?
 And I have to say, OK, case circle, case triangle,
 and have the different drawings for that.
 And he's like, this is a mess.
 You could never do something like that.
 Instead, what you want to do is make a hierarchy where
 it matches the domain model.
 I've got a shape class, and then he
 derives from it the triangle class,
 and it has a virtual function, and all those sorts of things.
 This is right in the first papers
 where people are selling this concept
 in certain programming languages, right?
 And I guess I should also point out
 that he says things like,
 when we're talking about object-oriented programming,
 literally what we're talking about
 is inheritance hierarchies with virtual function calls.
 Like, he says that, and he says object-oriented programming
 is programming using inheritance.
 So hammering home that this is literally
 what we are talking about.
 There's so much evidence, and I'm just picking one paper.
 Now, a lot of people will talk about, say, Alan Kay,
 because he was a big father of object-oriented programming.
 He's the one who coined the term, as far as anyone knows.
 And he talks about this sort of idea
 that OOP only means like messaging
 and a few other things, right?
 He said this.
 And so some people might be like,
 well, that's what object-oriented programming was
 really about.
 No one was ever pushing it.
 And OK, whatever.
 C++ is terrible.
 Don't listen to that guy, despite the fact
 that he made the language that's one of the most prevalent.
 It's the one that we all use, mostly, or at least
 have for the past 20 years.
 And so, this is the truth, this is the actual truth here.
 It's like, yeah, he said that in 2003, right?
 He said that after a very long time.
 So, why'd he say it?
 It's because 10 years earlier,
 he was already saying he kinda soured on it.
 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, you know, it's really good,
 but no one can figure out how to use it, I guess.
 So that's a little bit weird, I don't know.
 Maybe Alan Kay, he still comments on stuff,
 Maybe he'll come to tell us what he actually
 was trying to say there exactly.
 But if you go back earlier, because small talk is a lot
 earlier than that, if you go back
 and look at what they were actually
 talking about when they were talking about small talk,
 in the times before they had a chance to reflect and say
 that it didn't work, well, here's what they were saying.
 Inheritance programming shows the power
 of differential description, right?
 They're like, you can take an object,
 and I can say, I'm going to start with this completely
 undifferentiated object, and then I'm
 going to derive a rectangle.
 I'm going to drive, drive, drive.
 And in fact, here is a diagram from one of his articles
 talking about cool things, computer architectures,
 like we can have a generic object,
 and then we can drive from that a rectangle,
 and we'll drive a window, and a pane window, and a browser.
 Look, everyone is talking about literally representing
 in the hierarchy what your domain model is.
 That's what they're talking about.
 And if you need further proof, look at what's
 actually in Smalltalk.
 We have all the data for this.
 All of the papers exist.
 Here is an example from the art and science of Smalltalk
 where they're talking about some stuff that's
 needed to adapt values, like I want
 to convert values between things and actually exchange
 values between objects and stuff like this.
 And here's just a hierarchy that they
 drew of stuff that they were using for implementation.
 That's the hierarchy, right?
 And if you look, it actually says, well, it's
 only part of the hierarchy for this thing
 because we couldn't fit it on the diagram.
 We had so many classes we were inheriting here, right?
 And guess what?
 If you liked the shape example that keeps coming up,
 that everyone says, well, no one would ever actually
 suggest that you use this sort of ridiculous shape example.
 You know, you're just cherry picking,
 except it exists absolutely everywhere.
 It's in Smalltalk.
 There it is.
 They have a path class, and from that path class,
 they have different shapes derived from it.
 That's what the path looks like.
 That's in the base language of Smalltalk
 that Alan Kay and Robson shipped,
 and Adele Goldberg was the person who documented it.
 These are the original authors of Smalltalk, right?
 And if you don't want to take my word for all of that,
 You can take Bjarne's word for it.
 He criticizes Smalltalk for being all about inheritance,
 that that's all it was and you had to actually use it
 to get anything done in that language, right?
 And he's actually saying C++ at least
 doesn't make you do it that way.
 You only have to do it that way
 when you think it's a good idea, right?
 Which, by the way, I agree with him on that.
 That's why we were able to,
 that's why I'm still able to use C++ to this day
 is because Bjarne Stroustrup was actually really smart
 about a lot of things and he didn't try to force you
 to do things only his way, whereas Smalltalk kind of did.
 All right, so now that we've got that out of the way, let's talk about the origin story
 for this guy right here, who has caused me so much pain, you know, I won't even go into
 it.
 Anyway, let's talk about the origin story.
 So we'll start with C++, because obviously that's the most impactful language that really
 promulgated this inheritance hierarchy concept out to the world in a way that we all kind
 of experienced.
 only in programming C++, but obviously languages like Java, which are incredibly prevalent
 in not exactly our circles, maybe, but obviously in business world and that sort of thing.
 So it's not even just C++. It's like the knock-on effects of C++ also. So this is really, really
 important as an entry into where this came from. So let's start in 1978 and looking at
 that. And Bjarne Stroustrup is actually in the he's in university at this point. He hasn't
 actually gotten to Bell Laboratories, where he would do the later work on C++. So he is
 working on his PhD thesis. And again, as I'm going through the historical record here,
 I really want to try and give you a mindset of what the people were thinking as far as
 I could get it from their writings, right? I went only through primary sources for this,
 and I tried to figure out what were these people feeling, like what were they doing
 when they were coding? And so he is actually working on distributed systems. He's not a
 a languages guy. He's not there researching languages or anything like that. He's working
 on distributed systems. And what he wants to know is, look, we've got some stuff where
 we want to know about hardware protection, like, you know, if you kind of think of virtual
 memory or things like that, where you have hardware features that are designed to protect
 different parts of your program from other different parts of your program or different
 processes from each other or different nodes in a system, all those sorts of things. So
 he's doing distributed architecture work. And what he wants to do is run simulations
 is because at the time, again, putting you in the mindset
 of where we are in computer history,
 you don't just have computers lying around
 like we do today, right?
 It's not like, oh, I can just buy a bunch of computers
 and set up a network and do testing on it.
 It's like, no.
 There's no way he was gonna get things
 like a distributed multiprocessor system
 to just play around on in 1978
 unless he was extremely important
 in working for the military or something like that, right?
 So what he had to do was write a simulator.
 And what he decided to do to write the simulator,
 because earlier in his career,
 He had been in university, early in his education, I should say.
 He had been at university, and he learned from a person named Kristen Nygaard,
 who was actually one of the creators of Simula.
 He learned the language Simula directly from one of its authors, basically.
 He was actually there at the time when the author was also there,
 and this was how he knew what Simula was and how to use it.
 And so what he did was he wrote a simulator for distributed systems in Simula,
 which is kind of exactly what it's designed for, right?
 It's a simulation language.
 language. And he had a great time doing it. He was like, this was so much better than
 what I'm used to. I really liked the experience of writing that. So he ended up with this
 thing where he had like little programs that were simulating what was happening in a distributed
 network or distributed system, I should say, not necessarily on a network. And he found
 that it was really easy to debug the little programs by themselves, and the language made
 it really easy to do that. Now, again, it's important to remember, keeping all this in
 your head if you can. I know it's a lot. It was a lot of reading, right? So I'm trying
 to convey it to you, and just pointing out,
 it's important to remember that that's the domain model he was
 working with, is lots of little programs
 that were talking to each other, right?
 So anyway, he says that the class concept the Simula had,
 because it had the same sort of idea of a class
 as C++ would later have, he said that that class concept
 that Simula had was really good for direct mapping, right?
 Remember I said compile time hierarchy that
 exactly models the domain, right?
 He said that was working really well when he was implementing.
 He was just saying, oh, this is the thing
 I'm trying to simulate, and so I'm literally
 going to create classes in Simula that model that directly.
 And that was working really well for him in Simula.
 And we can kind of start to see how this is breaking down.
 He happens to be working on something that is literally
 a domain model of things that are encapsulated.
 The computers can't talk to each other.
 The different processes in the computer
 can't talk to each other.
 It's an exact fit for what a class actually does.
 This is important to remember.
 OK.
 So we used hierarchies for this.
 They weren't necessarily particularly deep,
 but they were the kind of thing where it's like,
 I have a computer.
 I derive different things from the computer.
 And those things are just kind of self-contained.
 And he had a really great time doing this.
 Again, he said very positive things about it.
 And one of the things that he really liked
 was the fact that the type system, when
 you have these hierarchies, that type system
 would catch errors for you.
 exactly the kind of thing that we maybe take for granted today,
 because most languages, even JavaScript now
 has TypeScript, right?
 Most things that we work with today
 have the ability for you to do this kind of type
 checking that catches a lot of errors at compile time.
 That was relatively new at the time.
 And I don't mean new in the terms
 of no one had ever thought about it before,
 but I just mean a lot of languages
 you might be using at this time still
 had very weak type systems.
 And in fact, Stroustrup complains directly
 when he's talking about this that using Pascal kind of sucked
 And he didn't really like it because the type system didn't
 work very well for expressing things and for catching errors.
 He felt it was kind of more trouble than it was worth.
 So that forms his basis for this idea
 that classes are really good and type checking on classes
 is really good, right?
 And just to split those down the middle,
 I do think the type checking part's pretty good.
 It's maybe the class part or rather the hierarchy part
 that I'm like a little bit suspicious of, right?
 But at least half of it I'm with him on already even.
 OK, so that's sort of what you will
 see if you read the Wikipedia or something, right?
 That's the simple part, and they often leave a lot of stuff out.
 So I thought, because this is the Better Software Conference,
 I would include a much more interesting aspect
 of this story, because you would think,
 if you saw a thing that's like, hey, what happened
 was Bjarne Stroustrup was doing stuff
 with distributed systems, and he wrote this thing in Simula,
 and it was a great time.
 And so what he decided to do when he got to Bell Labs
 was make C++, and it would just have the classes in it
 from Simula.
 It was great.
 No.
 So what actually happened was the entire thing completely
 rolled over and died.
 He tried to run the Simula program,
 and he had all sorts of problems with it.
 And it started even before he tried
 to run the Simula programs that he was writing.
 What actually happened is, first, he
 hit the same things we hit with C++ today.
 Build times were through the roof.
 And it was almost impossible to make changes to the program.
 So much so, and I'm going to let this sink in for a second
 because it's really awesome.
 So much so, I mean, I almost want you to read it.
 If you compiled 1.30 of the program and tried to link it,
 it was slower than just recompiling the entire thing.
 OK?
 Let that sink in because it means
 that Bjarne was talking about Unity builds in 1994.
 He was like, we can speed this up by not doing incremental.
 Incremental builds sucked that long ago.
 Anyway, but I digress.
 Anyway, the runtime also was lousy.
 He couldn't get the thing to run fast enough
 because Simulo was extremely slow.
 Anyone want to guess why it's slow?
 It's a rhetorical question.
 I'm going to tell you why it's slow.
 It was slow because of the garbage collector.
 Same reason things are slow today half the time.
 The garbage collector was taking 80% of the runtime,
 apparently, even though there was no actual garbage that
 needed to be collected.
 Because I guess at that time, garbage collection
 was even very, very primitive, obviously.
 So it was probably running all the time
 just to see if there was any garbage.
 And it was like, yeah, no garbage.
 And that was happening a lot, so 80% of the time.
 He had the experience with Stimula
 that we have with C++.
 The chain continues, right?
 The garbage collection, obviously not so much.
 So that's what happened.
 He had to rewrite the whole thing from scratch in a different language called BCPL, which
 has no type checking whatsoever.
 I mean, that's not entirely true.
 It has very, very minimal, but none of those class things and that sort of thing.
 So that's the actual story of what happened.
 So it's kind of interesting.
 It presages everything, right?
 The whole thing is almost like a microcosm.
 So if we reflect on this for a second, again, I think I've tried to highlight the important
 points there, but the other thing to remember is a lot of people talk about these things.
 They talk about those compile time hierarchies
 and all that sort of stuff.
 And they say, you know, here's the thing
 that you just don't understand.
 It's all about large teams.
 You know, it's all about these large teams.
 It's just that you've got to have large teams.
 And if you had large teams, then you
 would understand the magic of the compile time hierarchy
 stuff and the encapsulation.
 It's amazing, right?
 How big was the team that Bjarne Stroustrup was working
 with when he figured this stuff out and thought it was good?
 One.
 He's doing the same thing we're doing.
 So these ideas don't come from some kind of analysis
 of what we're gonna do with lots of people.
 So you could argue maybe they turn out to be good for that,
 but you certainly can't argue
 that he was designing it for that,
 because they weren't.
 They were doing it for themselves.
 Strucci was doing it for the protection,
 the type protection, the error tracking,
 that sort of thing.
 He wasn't doing it to,
 and also like the virtual function kind of stuff.
 He wasn't doing it for large teams
 because everyone at Cambridge University
 helping out in the project. No, he was a lone wolf coder, he really was. So anyway, he goes
 to Bell Labs, he makes C with Classes, which is the first thing that, the original name
 of C++, called C with Classes, because that's what it's going to be. It's going to be taking
 stimulus type system and putting something like that into C, and the reason for that
 is pretty obvious. He goes to Bell Labs, and C would be like a lingua franca there probably,
 right? Because they're the people who make Unix, they're the people who make C, like
 the people who are at Bell Labs, the people making these technologies. So he is tasked
 when he gets to Bell Labs with doing the same sorts of distributed systems analysis that
 he was trying to do at Cambridge. He's trying to do those things for Unix. He wants to analyse
 certain behaviours of it and that sort of thing, and he finds the same exact things.
 He would like to write in something like Simula. He doesn't want to have the same disaster
 that he had where he had to rewrite everything in BCPL. So he's like, could I take C, add
 classes to it and get the best of both worlds. Something that actually runs and doesn't fall
 over, right? But that has some of these features that I've been enjoying. And so that's what
 he's doing, and he's doing it for the same reason, right? That sort of modularity and
 concurrency analysis kind of stuff. He's trying to figure out how these things work and run
 simulations of them. Same exact thing is happening, and it's happening over again. And what he
 kind of complains about with C, if you didn't have these things, some of it's a little
 confusing. He talks about the fact that he says all program parts can poke into all of
 the memory, and C++ doesn't really change that, but I think he's just kind of talking
 about private declarations, right? He's just like, well, you know, obviously I don't think
 you can stop programs from poking into the memory by putting private on it, but it will
 stop programmers from typing it into the compiler, and that's sort of the same thing, right?
 And where that comes from, this sort of idea that we're going to protect things, that actually
 comes again from his distributed systems sort of OS thinking background. Because he's looking
 at hardware, and he's looking at things like virtual memory and protection that you get
 between processes and those sorts of things, and he's saying, that's kind of what I want
 for programming. I don't really want to make those mistakes where I access the private
 part of things. I want to be able to wall those off. And he's thinking about actual
 hardware, computer hardware. That's where that idea comes from. Again, it doesn't even
 It doesn't come from working on large teams
 or anything like that.
 It comes from thinking this might be a nice feature,
 just like the computer stops it from happening,
 the compiler could stop it from happening.
 And that's where const comes from too.
 It comes from an OS metaphor.
 He's thinking about whether or not files
 have write permissions to them.
 Are they read-only or are they writable?
 That's what const is to him.
 That's where he thinks about it first.
 So again, all these things come from a very different place
 than what you would think if you didn't go back
 and read the historical documents.
 And by the way, these aren't hard to find.
 These just come from the D&E, which is a very popular book that he wrote
 that's just a collection of his papers, right?
 So a lot of this stuff in the first part of the talk,
 you don't have to dig that hard for.
 All right.
 So anyway, we get to sort of a second wrinkle at this point.
 And what happens when he starts using this stuff is it's important to...
 I shouldn't really say what starts happening.
 Let's say one of the things he does is he uses the inheritance
 that he puts into this sort of C with classes because he's just going to do the same thing
 that was happening in Simula. He uses that inheritance in a way that would generally be
 frowned upon even by him today. And that is to do things like implement a linked list and reuse it.
 So what he does is he says, okay, I'm going to take a block that's like the linking part of things,
 and I'm just going to inherit stuff from it so that all the things that inherit from it can go
 in a list, right? Now, he would never say to do that today. He would say use a template or
 or something like that, like a parameterized type, right?
 So, but it's important to remember,
 at that time, this was a thought.
 And this thought actually does come from Simula as well.
 We'll get to that later.
 But, so it's important to say,
 in addition to the modeling part,
 they're using inheritance for the purpose of code reuse,
 even if it really doesn't have much to do with anything.
 That's sort of an adjunct split.
 And I just want to include it here
 so that you understand all of the things
 that were being thought about with inheritance
 at the time when it was actually being put
 into more mainstream languages.
 So that's one of the things he was doing with it in addition
 to the domain modeling part, which
 is more of a direct mapping.
 And you can see him here criticizing it
 just to hammer this home.
 He doesn't think you should do that anymore.
 And he said as much in parameterized types
 for C++, which is where he started to talk about templates.
 As soon as templates, as soon as he got his answer
 to how we were going to do these sort of things,
 as soon as he got a parameterized type model,
 because that wasn't new to C++.
 There were languages like Ada and Clue and stuff
 that had that in there.
 He started to say, OK, C++ has never had a good way
 to do this because you had to do the inheritance thing.
 That's not fabulous.
 Parameterized types are the way to go.
 So he knows that, too.
 It just takes a while to get there.
 OK, so that's kind of the end of it.
 And virtual functions come in a little bit later.
 The first version of C with classes,
 when he's first starting on it, doesn't actually
 have virtual functions.
 He eventually does put virtual functions in.
 And when he does, this is what he says about it.
 He says, it was borrowed from Simula
 and presented in a form that was intended
 and efficient. So he was thinking primarily about, I want something kind of like what
 Simula has for this ability to call functions without knowing the type on them, but I want
 to make sure it's very fast, because that was a concern that he always had, again, because
 of the disaster he had experienced directly with Simula. So again, reflecting on this,
 it's totally different from what you would think if you just read the capsule summary.
 He's not talking about large teams still. He's talking about literally we're just working
 on this thing, I'm using inheritance for some reuse of code, and I'm using it to directly
 model the compile time. I add a compile time and use it to directly model the actual domain
 that I'm working in, which happens to be distributed systems analysis yet again.
 So we have to jump at this point because that's pretty much all we can get out of C++. I mean,
 you kind of got the picture now. Everything else is like after the fact. Everything else
 is post hoc. Anything else about C++ was people making stuff up after that, or adding
 things to it after that. But that's where it comes from. So if we want to actually know
 where these ideas started from, we've got to go back to Simula. We've got to say, okay,
 if all this stuff came from Simula and him using Simula, well, where did it come from
 in Simula? Did they just make it up? And Simula originally comes from something called the
 Norwegian Computing Centre. We are here very close to Norway, I suppose. Some of you may
 have known this place. I didn't know anything about it until I was reading up on Simula.
 It's a quasi-private public institute for doing computing research. It's in Oslo, Norway,
 and in 1962, these saucy gentlemen right here, and I'm apologising, Sweden is the worst place
 to give this talk because now I have to pronounce their names in front of people who probably
 know Norwegian pronunciation very well, and so I'm going to butcher it and I apologize.
 It's Ole Johan Dahl, maybe I can pronounce that correctly, and Kristin Nygaard. And you
 already know Kristin Nygaard's name because this is the person who Bjarne Stroustrup learned
 the Simula from originally. He interacted with him a lot when he was at his previous
 university before Cambridge. So these are the folks who make Simula. They're the people
 who actually are kind of like the masterminds behind it.
 And the first reference we have to it
 is in private correspondence that has now
 been published from Nygaard to another person who
 was working on operations research.
 And these folks' operations research,
 if you don't know what that is, it's
 when you look at how systems are behaving in order
 to optimize them, basically.
 So you can think about things like we're
 trying to plan how the military is going to organize some
 things, like what is their process going to be,
 and we want to maximize the throughput of like how we're manufacturing this thing
 or how we're going to load planes onto an aircraft carrier.
 I mean, I don't know anything like that, but a lot of it's military
 because that's where the funding comes from, but it's for anything really.
 It's also in business, operations research, things like the Simplex algorithm,
 if you've ever heard of that, that's operations research, et cetera, et cetera.
 So anyway, he says like, I got this idea.
 What I'm going to do is I'm going to make this language
 that makes it very easy to describe one of these systems,
 and then what I will do is use it to describe these problems in a way that
 allows it to do the simulations automatically so it's like almost like a
 scripting language for system simulation and if you look this is some code you
 can find when they talk about the history of it this is in 1963 the
 similar language would have looked like this it's one of the earliest snippets I
 could find and so this is not the way the final
 look, this is sort of how they started out, and you can see what it essentially is, and
 you don't need to understand exactly what's going on in this for the talk, so I'll spare
 you the details, but essentially what you're doing is you're setting up these various things
 like customers and stations, it's like things, we're imagining like entities moving between
 parts of a system, and we write little pieces of code that's like how they will be processed
 when they get there, like will this person, you know, they'll be held for a little bit
 of time, and then we'll check to see if they've paid the fee, and if they've paid the fee
 We'll send them to this station.
 If they haven't paid the fee, we'll send them
 to this other one.
 And the idea is you just describe that system this way.
 You run the simulation, and it presents you
 with a bunch of statistics.
 So you can kind of see like, OK, this
 is where the bottlenecks were, or things like that.
 And that was very successful.
 They eventually released a thing called Simula 1,
 which is the first sort of more widespread version
 of this thing.
 People loved this.
 They could do their system analysis this way.
 But Nygaard and Dahl were thinking in their head,
 like, we really like this thing, and we
 think it has a possibility to be bigger than what it is,
 a possibility to be more powerful than just what
 we had in that first version.
 So they start to make a new version, which eventually goes
 on to be called Simulus 67.
 And it's like Windows 95.
 At this point in time, people are
 starting to name languages where you append
 the year of the language after the language.
 So we have things like ALGOL having that,
 or COBOL 60 is the version of COBOL
 that was first introduced in 1960.
 And so that's what Simulus 67 would eventually be.
 And they're trying to figure out what
 they're going to do for this new version.
 And what happens is they're thinking about code reuse.
 They're like, we don't really like
 we have to rewrite things a lot of times.
 And we're trying to figure out some way
 that we could get some of this reuse in there.
 We want to reuse these things, and it's not really
 working out very well for us.
 They're looking for a solution to this,
 and they're not really finding one.
 But eventually, when they're thinking about this problem,
 they're saying, what if we have a bridge with a toll booth
 on it and we've got cars going across it
 and they might be either trucks or buses,
 what could we do so that we could just write this once
 and have it work for both the trucks and the buses
 so we don't have to duplicate all the stuff we said
 for trucks and buses?
 That's what they're thinking of.
 And this is not me saying this,
 this is them saying this is what they were thinking,
 this is what they were trying to solve.
 Literally, this is what they were trying to solve
 when they came up with classes.
 And here is what those classes look like.
 You can see up at the top there, it's defining link class car.
 The link is a thing where they have this linked list
 sort of superclass that they're deriving from.
 And they're going to have a car.
 Then they're going to say underneath cars,
 they're going to derive a car class truck and a car class
 bus, there's different kinds.
 You can see load and capacity are
 like two different data members that those have.
 So in this one snippet, we can see both things
 that not only they are about to do,
 but that Bjarne Stroustrup is about to do as well.
 We are using this for reuse.
 We are deriving from a link class
 to get its functionality, not because we
 think that we are like a link in the domain model.
 But then mostly what we're doing is following the domain
 model with our classes.
 It is car, and underneath it, it is truck and bus,
 exactly like would eventually be promulgated
 as how to design OOP systems with those hierarchies
 that I was talking about.
 So that's what it looked like.
 And they literally said, hey, this now
 allows us to quickly just say, this thing's a link,
 and then it can go in lists.
 Awesome.
 Now, you'll notice they didn't actually talk at this time
 very much when they were counting the history.
 And I guess I shouldn't say you'll notice.
 I noticed, because I had to read the whole thing.
 They don't really talk about the virtual function
 part at the outset.
 They're kind of talking about just this reuse part.
 That's mostly what they're concerned about.
 But they do eventually care about that virtual part,
 because once they do this subclassing, they're like,
 hmm, we want to have ways that the subclasses can do things
 in addition to what the parent's doing.
 And that's where the idea from virtual functions comes from.
 They say, we have these operations
 that we were defining, things like what that queuing behavior
 was going to be that I showed on the original slide from Simula
 back in 1963.
 And they're like, we want to have those operations be
 modified based on whether this car is a truck or a bus
 and things like that.
 So that's what happens.
 Now, if you look at how this had to actually work,
 it works the same way that primitive code reuse works.
 If you wanted to use it today, if you
 want to use inheritance for things like links,
 it worked exactly the same way.
 They literally have the sort of class arc,
 as I can see in the middle there,
 class simset and simset class simulation.
 That's basically saying, look, all this stuff
 is going to be derived from linked list holder.
 That's what simsys would be like.
 I'm a person who holds linked lists.
 And then we're going to derive the simulation from the thing
 that holds linked lists.
 That way, it can use that.
 So it's almost like a library.
 Like, they're using inheritance like a library here,
 as well as the domain model, which is under it.
 So again, that same double duty.
 All right.
 So again, just a hammer at home, nothing about teams,
 nothing about architecture, none of this stuff, right?
 It's all about trying to solve a code reuse problem,
 and then something falls out of that.
 No analysis is done of any of the things
 that you would normally say if you
 were trying to promote the use of domain modeling
 via those class hierarchies.
 That's not what's happening.
 So this is where we actually got compile-time hierarchies
 of encapsulation that matched the domain model.
 Because Simula actually did have encapsulation.
 You couldn't refer to things outside of the entities
 like that very much.
 And so it kind of did have the beginning of that.
 It wasn't as rigid as C++, as we'll see.
 But that's effectively what it was.
 So I don't know how to summarize all of that that we just saw.
 Basically, what I'd say is, effectively, what we sort of
 were seeing is this came out of sort of an approach
 to templates that wasn't very good.
 Like, that's sort of what happened.
 And it's not their fault, because, I mean,
 they're in the wilderness, right?
 Like, nobody knows any of this stuff.
 We take for granted all the things we know today.
 They don't know any of this.
 They have to invent everything.
 But that's really what they almost wanted.
 If you had handed them templates at the time
 they were trying to do this, they may never have invented
 this class concept at all,
 because they just wanted a linked list.
 They just wanted a way to say,
 I have a list of things going across, right, or whatever.
 So that's sort of where they had started,
 and they just happened to come up
 with a virtual function thing,
 which by the way is useful for stuff,
 I'm not trying to suggest that it isn't,
 but that was sort of a byproduct
 of what they were trying to do,
 which was just make a list class they could reuse, kind of.
 All right, so that's the end, that's the entire story.
 Now you know where everything came from.
 I mean, of course, if you only wanna do
 sort of the capsule version, that's, you know,
 again, sort of the Wikipedia version of it.
 But you have to kind of ask the question,
 I mean, we know that they did those things,
 but like, where did they get the idea for those things?
 I mean, that's usually how I approach things anyway, right?
 I'm like, after I find out that, like,
 someone got the idea from someone,
 I'm like, well, do we know if that guy
 got the idea from someone?
 Because I wanna know about following it
 the whole way back, right?
 So that's the end if you just use a capsule Wikipedia
 summary again.
 You'd kind of get something like that out of it.
 What you probably wouldn't get is this stuff.
 So when you actually go digging in here
 and you pay attention to every little thing,
 and every time you come across something
 that someone mentions, you're like, wait, what?
 And then you go try to pull the papers
 that they're actually referencing.
 You start to find out a lot of other stuff.
 So if we keep pulling this thread, what we find
 is the idea of subclassing is not credited
 to Nygaard and Dahl.
 They credit it to somebody else.
 C.A.R. Hoare, actually.
 The guy who invented Quicksort.
 That's who they say this idea of subclassing came from.
 They don't claim to have invented it.
 They claim to have invented a version of it
 that was derived, pun intended, from Hoare's work.
 And this is the paper that they're referring to.
 This is the paper that I believe they would have read,
 although I'm not sure exactly which version they read
 because different versions were circulated
 and there's actually sort of a further comments one
 that happens after this,
 but they would probably be aware of all of this
 because academics are always very good
 at sharing their information this way,
 putting out publications.
 I mean, it's the thing that is cred for them, right?
 Like your papers are your cred.
 So you're reading papers by other people,
 you're writing your papers.
 So they read this paper for sure.
 Which version exactly, I couldn't tell you.
 But this is the paper, and here's
 what Hoare is talking about in this paper.
 He says, all right, we have in the real world,
 and I want to underline that because it's
 like compile time hierarchy that matches the domain model.
 In the real world, we have objects
 that we want to model, and they have
 different versions of things, and we
 want to model that sort of discrimination that's
 happening there in the subclasses.
 And so he gives the example of an algebraic expression.
 He's like, if you look at algebraic expression,
 I'm trying to model that.
 I want to represent that in the computer.
 I might say I have an algebraic expression.
 And then I have these different things
 that are types of algebraic expressions, right?
 And he says constants, variables,
 dyadic expressions, right?
 He's trying to model language.
 And by the way, this happens a lot.
 I don't really cover it much in this talk because it's not
 relevant, but you'll see a lot of people this time
 were working on things like, how do we parse stuff, right?
 So thinking about how do we parse language,
 how do we parse computer languages,
 how do we parse human languages,
 for thinking about this kind of thing all the time.
 It's like, what if I want to represent an equation?
 How am I going to do it?
 And he's saying, what about these subclasses?
 And he would literally write it just like this.
 So as we can see, Nygaard and Dahl were not lying.
 They 100% did get this idea from that.
 It looks almost exactly like theirs, down to the syntax.
 You can see that he's saying, I'm
 going to have an expression.
 Here are the subclasses of the expression.
 It's going to be constant and variable.
 And so this is what Nygaard and Dahl read.
 And they were like, oh, wait a second.
 What if we just had our cars and trucks and buses under them,
 and then we could just use the car,
 and then we put the car across the bridge?
 OK, that would work.
 Wait, but we don't have to stop at the car.
 We could make something above the car that's
 things that are in a list of stuff,
 and then we could use it for everything.
 It doesn't even have to be the bridge.
 Holy cow, dude.
 Thank you.
 Thank you, Tony.
 So anyway, yeah, Anthony, they call him Tony Hoare.
 He didn't go by Anthony.
 Anyway, sorry, thing I didn't introduce ahead of time.
 It's just up here because I've been reading this stuff
 for, I don't know, months at this point.
 Anyway, so when he presented this in this paper,
 it doesn't stop there.
 And this I found so interesting.
 And we're starting to get into stuff now
 where I had never heard before.
 A lot of this stuff, when I digged into it,
 I was like, how come everyone doesn't know this?
 Because it's super cool.
 When he presented this paper,
 or I shouldn't say presented this paper,
 when he wrote this paper, he included discriminated unions
 in it, tagged unions, whatever you want to call them.
 If there's FP people out there in the audience,
 they're going to scream at me for using the wrong term.
 But you know what I'm talking about,
 something that has a type in it and then subclasses inside it.
 And you don't know which one you have
 until you look at the type.
 And then you can use whichever part makes sense for that type.
 And this is a super powerful programming idiom.
 I use it all the time.
 And I think it's one of the best programming tools
 you have for things like dynamic polymorphism.
 I absolutely love it.
 It's in this paper in 1966, a long, long time ago.
 And this is his way better than anything
 I get to use today in C++ thing he suggested
 for what you would do when you wanted to use one of these.
 He said it's a switch statement, which, of course,
 wouldn't have been called a switch statement at that time.
 But it's basically a switch statement that says,
 I want to use this object.
 I'm going to tell you what each type, whatever
 the subtypes might be.
 I'm going to give you a different block of code to run,
 depending on which one they were.
 Again, functional programming, I believe,
 would really like something like this.
 It's doing that discriminated union thing.
 And furthermore, he gets the fact
 that this adds type safety and prevents errors.
 He gets the fact that the code that
 would come after the then statements
 can now safely refer to the subtypes
 because you know you've checked what the type actually was.
 And he says that right in the paper.
 So he totally got it.
 he knew way better than any of the knock-on languages,
 sort of, I guess, from C++ on,
 he knew way better even at that time
 how cool discriminated unions would be
 if you had the right language constructs
 to work with them in a type-safe way.
 So I thought that was super-duper awesome.
 Now, if you think about it,
 if this was in the paper, and Simula read the paper,
 and that's how they created Simula,
 or the class concept in Simula and the idea of subclass
 Simula.
 And then C++ came out of Simula.
 Well, why don't we have, like, why wasn't this
 a first order feature?
 Like, where did the discriminated union part go?
 And the answer is, well, Nygaard and Dahl actually
 put it in.
 It was called Inspect.
 So Simula actually had this.
 You didn't have to use virtual functions.
 Simula was way better about that.
 When Stroustrup went to do his classes, he took it out.
 He thought that discriminated users were bad because they
 broke modularity, right?
 It's because now someone from the outside
 can tell what class you are.
 So we lost out on one of what I consider
 would be one of the most important features
 I would use in C++ every day because it got removed
 when Simula was playing Telephone with C++.
 All right.
 So there you go.
 That's where the concept actually comes from, right?
 It's this paper by, you know, Anthony Hoare.
 He's sir now, by the way.
 He's been knighted, I believe, right?
 And again, not a single part of it, there's no hint at all that any of this is really
 about compile time hierarchy stuff, or about large teams, or about anything to talk about
 today, it was literally like, hey, I might have a record that wants to have a type field,
 and it would be cool if I could just switch on the type field and do different things
 based on it. How about that, right? And that's what I would have wanted. So we had that already
 back when this paper circulated in 1966. So really the whole string is about us getting
 a really bad version of discriminated unions.
 We had them already, and now we don't have them.
 To this day, I don't even know a standard variant really works as well as this thing
 would have, right?
 And we could have had it from day one if someone had just believed that this was good.
 All right, so that's the actual end.
 We've gotten back to kind of the point of the first part of the talk.
 Here's another half because it goes way further back than that.
 But I want to give everyone a chance to kind of stretch out.
 So I don't know.
 Can we take a break?
 Where is Sam?
 Can we take a break for a few minutes?
 Yes.
 How long do you want?
 I don't care.
 I can keep going if you don't want, but I figured, yeah, I'll give it a stretch.
 Let's go to 25.
 Okay.
 Get everyone back here whenever that is, at 25.
 Okay, so as you saw in the first part,
 you come to the end a lot of times,
 but then it's like, well, is it really the end?
 You keep digging, turns out you didn't really get
 to the actual meat of the origin story.
 You didn't really get to the part where,
 I don't know, I'm bad with comic books,
 but Bruce Wayne and the Falling Pearls
 and the Joker and that kind of stuff.
 We've actually gotten back to that scene,
 and that's the scene that everyone wants to see
 in the movie, it's like, how did he become Batman?
 So what we're gonna do here in the second half,
 I promise there's only, there's only this one more half,
 there's two halves, I'm not gonna, it's like, yet again.
 What we're gonna do here is,
 we're going looking for Batman, right?
 So, we left off, we've got this paper
 on record handling by horror, right?
 famous for Quicksort, like I said,
 one of the fathers of computer science.
 And the interesting thing is,
 and this was really hard to figure out,
 but I was trying to, like, where did he get the idea?
 Like, did he come up with the idea?
 Was he sitting around?
 What was he working on, right?
 And it was really hard to find this.
 I wish that I could find a document
 where he talks about it.
 If any of you out there ever find a document,
 because, you know, I did the most research
 that I could do in the time that I had
 to figure out where these things came from,
 but I'm sure I missed something somewhere.
 So if I'm not gonna actually figure this out,
 I would love to see it.
 But after a lot of digging,
 I figured out something pretty interesting,
 which was that actually,
 there was this committee
 that was supposed to update ALGOL.
 Now, ALGOL was a programming language
 that was very popular at the time.
 It was in use since the early 60s, actually.
 Actually, it might even have been before that.
 I don't remember,
 it's not that relevant to this particular timeline.
 But what they were going to do is,
 much like Simula had an update from Simula 1 to Simula 67,
 here there's going to be an update of ALGOL up
 to this new version that would eventually be called ALGOL 68.
 And the people who are working on this,
 it's like a who's who of computer science fame, right?
 So horror is on this, and so are a lot of other people,
 like Nicholas Wirth and that kind of people.
 The person invented Pascal or created Pascal, right?
 So on this committee, there was another guy,
 and his name was Douglas T. Ross.
 And this is a name that I had never seen mentioned
 ever before, I have no idea who this guy is.
 And I'm like, wait, what?
 And, oops, sorry.
 And when I was talking about it, it was like,
 oh, you know, in some private correspondence,
 because Alan Blackwell and Kerry Rodden,
 not really a part of the story,
 but they're like, we talked to Hoare privately
 about where he got those ideas,
 And he said that they actually, a lot of them
 came from this guy named Ross, who he had conversations with
 when they were on the committee.
 And I'm like, OK, so what's this about?
 And Ross had this thing he called
 a plex, which is a record-like data structure.
 And apparently, this was something
 that really influenced Hoare's record handling paper, which
 would eventually go on to create the rest of the chain
 that we just went through.
 So that's one thing.
 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.
 So, but it's another huge branch
 of object-oriented programming.
 Small talk was very important.
 It's influential, at least in the research
 or in the understanding of OOP, right?
 It was very pure OOP language.
 It pushed OOP a lot further
 than a lot of other languages by saying everything
 is going to be object-oriented and that sort of thing.
 And of course, it invented the term object-oriented.
 So everything is going to be like Smalltalk, which
 is what object-oriented was, right?
 If you look at what Alan Kay talks
 about for his inspirations, like where did he
 get his ideas from Smalltalk?
 He lists some things.
 And there's something like the Burroughs B5000
 and this file system from an Air Force base
 that had to do mostly with dispatches.
 We could go into that in the Q&A if anyone cares.
 But one of the things he talks about
 is Simula, which we've already covered.
 And the other thing is Sketchpad.
 He talks about Sketchpad all the time.
 This was a hugely impactful thing for Alan Kay.
 And Sketchpad was like this drawing program, right?
 I was aware of Sketchpad.
 Maybe some of you are aware of Sketchpad.
 It's pretty famous.
 You can look up demos of it on YouTube, for example.
 So we've got this Ross guy that I want to look into more.
 I'm like, what's going on?
 And then we've got the Sketchpad thing.
 And I'm like, hmm, I think I remember Sketchpad,
 but I don't really know why that would have inspired Alan Kay
 to do Object-Memory Prize.
 So I'm going to look into this more.
 I want to see, just make sure I've got the whole story
 before I really say the end like I fake did in part one.
 So let's go back even further.
 1952 now.
 There's this place called the Servomechanisms Laboratory
 at MIT, which is kind of an amazing name.
 I would love to be able to tell people
 that I worked at a Servomechanisms
 library, a laboratory rather.
 But this fellow right here, that is Douglas Ross,
 who now I know exactly who he is and what he did.
 He goes there and he's first on the job in 1952.
 He gets to this laboratory.
 And what their sort of whole mission was,
 this was Department of Defense,
 United States Department of Defense research stuff.
 What they were trying to do is build a system
 where someone from like the Air Force
 could describe a part that they were going
 to try to manufacture, and the computer would just make it.
 It's almost like the birth of 3D printing.
 And they actually did demos of this,
 they had stuff working where you could type in
 a description of an ashtray in this sort of pseudo language
 that they had that was meant to be kind of more,
 it's sort of almost like in a Grace Hopper sense,
 like something that's sort of,
 we're trying to get closer to human language,
 but it's really not human language
 because they don't have the ability to parse that yet.
 I mean, until large language models,
 we didn't have the ability to parse that, right?
 So, when you look at something like this,
 what they're trying to do is say,
 pseudo-language and our milling,
 our automated milling system produces
 like this object out of it, right?
 And they actually have working,
 it's not, they've got it working,
 they have instances of objects
 you can actually look at that they made.
 So they're accomplishing this as well,
 and you have to remember how early this is.
 1978 is, you know, I date these
 by when the person's talking about it.
 This is the 1950s that they're doing it.
 So they're working on this simulation stuff,
 I'm sorry, this processing stuff where
 they're trying to take language and turn it into sort of CAD,
 the birth of CAD.
 And just to show you how early this
 is in the thinking about what's going on in computing,
 COBOL is generally like, again, in the kind of low effort
 Wikipedia search version, COBOL would
 be the first thing you'd see referenced
 as having things like record-like structs.
 Like, we all take a struct for granted.
 We're like, a struct is like the simplest possible thing.
 It doesn't have inheritance, or it
 doesn't have virtual function calls, or any of that stuff.
 We would just say, if we're just talking about a bare struct,
 a basic vanilla struct, that doesn't really exist.
 No one's thought about that, really.
 They have sort of an idea of data records
 that comes more from data processing,
 like in the old IBM sense of the term.
 So they do have an idea of more of the database version
 of like I've got some fields that comprise like a record.
 But people aren't really thinking like when I program,
 the computer program is also going to be written
 in terms of records that it's using purely for computation,
 not to store a particular piece of data
 like on magnetic tape or something like this, right?
 But it's just purely an artifact
 of the implementation of this program.
 I've defined other records.
 They're not thinking about that.
 And even in this, in 1960, when this was printed,
 this first version of COBOL, even in that 1960 timeframe,
 this COBOL didn't really have that.
 All of its record stuff was pretty much still
 about data on tape kind of things.
 It was in memory as well when you had a mirror of one,
 but it wasn't, no one was thinking really about that
 as far as I could tell.
 They were just thinking of it as storing data.
 Now, Pedants will say that PlanCalcul has this,
 but it was a purely theoretical language,
 just written down on paper.
 It was an early German programming language.
 It's very forward thinking,
 so I don't want to disparage it at all,
 but it doesn't count if you just sort of wrote down,
 well, maybe we'll have this way to put multiple things.
 It's like, no matter how rigorously defined on paper,
 you don't get credit unless you've actually
 got this working and you're actually programming,
 making programs in it that you run, right?
 So really, it's kind of not there at the time.
 So what people are actually thinking about is this, right?
 Lisp is gaining some traction here
 because it's developed over the course of the 1950s as well.
 It gets published officially in 1960
 in this paper by John McCarthy, who obviously was one of the,
 I believe he's sort of the person who designed Lisp.
 And actually, a different person at MIT actually implemented it.
 But that has nothing to do with any of this.
 Point being, he's obviously the father of Lisp,
 because he's the one who had the idea.
 And he's the one that designed it.
 And he's starting to talk about Lisp
 and saying, this is a way that we
 could do symbolic computation.
 Now, remember, Lisp doesn't really
 have any concept of records at this point
 or anything like that.
 It's just sequential bags of stuff.
 So it's like, OK, we're going to have a list of symbols.
 And to the extent that you're ever
 going to do processing on something that's like a record,
 it's just up to you to kind of remember that the symbols will
 go in a particular order.
 And that's how you're doing your processing.
 So they haven't really gotten this idea yet
 of structured data, like this is what the computer's
 going to process.
 They're thinking in terms of processing lists, right?
 Because again, there's no high level languages.
 We've got Fortran coming in this time.
 We've got LISP coming in this time.
 And then these experimental languages, stuff like that.
 We don't have all these languages
 that we know about today.
 So Douglas T. Ross, he's also working on stuff like this.
 They have a programming language that they're working on
 for this computer-aided modeling stuff that they're doing.
 And he's actually thinking, what if we did structured data?
 What if we were computing on things that actually
 had a fixed size?
 And this is all throughout the 1950s.
 They're developing this.
 And in 1960, contemporaneous with that Lisp paper,
 he publishes a paper.
 And in this paper, he keeps it classy.
 Right out of the gate, he basically
 throws shade at Lisp.
 He's like, look, Lisp is kind of dumb.
 Why would we compute only on things that basically
 have a next and previous pointer,
 or like a tree where it just has a left and a right?
 What would give you the idea that the things
 you want to compute on only consist of two things?
 What you're doing is you're just using that,
 and then you're constantly building up
 these structures of two pointer things
 to represent bigger things.
 Why don't we just store the bigger things directly?
 And he knows why.
 He gets it.
 He says, look, not only does it take more space,
 but it also takes more processing power.
 Because we've got to reconstruct the data we actually
 want by plowing through these lists all the time.
 And furthermore, we have to store them
 by keeping all of that interstitial stuff in there.
 And that's no good either, right?
 So he is 100% on point, and this is published in 1960.
 Contemporaneous with the list publication,
 contemporaneous with something like Algol 60.
 So way, way ahead of the curve here, right?
 Because that means they had it running
 throughout the 1950s.
 Now, he calls this a plex.
 He doesn't call it a structure.
 He calls it a plex.
 Because I'm guessing he's bad at self-promotion,
 he never gets this term to stick anywhere,
 so we don't type Plex in front of our thing.
 But to be completely honest,
 as far as I can tell from history, we should.
 It should be called a Plex.
 We should pound to find Plex to be struct,
 because that's where the credit actually goes to.
 It's this guy right here,
 and the other people that were on that team.
 So what does it look like?
 This is one of the great things about this era.
 Everyone publishes everything.
 It's really nice.
 And it has to be condensed down into a paper
 because there's no YouTube.
 So I don't have to watch hours and hours and hours of things
 to find out what the heck is going on.
 This is an example of a complicated Plex.
 This is in the original paper in 1960.
 And what does it have in it?
 Well, it has some data, an x and y coordinate, for example.
 Just things that you might store
 like you would normally data members.
 It also has pointers already.
 These are basically things that are linking it to other things.
 So we've got data members.
 We've got linkage members.
 And hold onto your butts, because what is this stuff
 down here?
 What is that?
 And I'm loving this, by the way, when
 I find this stuff in papers.
 Because I don't like to just read the abstract.
 I want to read the whole paper.
 I paid my money, and I want to see the whole movie to the end.
 Even with the end credits, even if the movie sucks,
 I kind of want to know.
 I'm just curious right now.
 So I'm looking at this.
 I'm like, what the heck is that?
 TRA 562?
 Like some secret code stuff going on.
 So what these actually are, and this is awesome,
 is check and fast are basically flags.
 And what Ross says is, look, when
 we're processing this stuff, think of it this way.
 We could run one subroutine, and just
 based on what we stick in the Plex,
 we could change how we're processing it.
 So if we do want this thing to go through a particular path,
 we set it.
 And if we don't want to go through a particular path,
 we don't set it, right?
 Just pausing for effect on that one.
 What's TRA 562?
 What's TRA 467?
 Those are addresses.
 That's an instruction.
 It's saying what we're going to do there
 is jump to a subroutine.
 Those are function pointers.
 So he basically says, sometimes, we
 don't really want parameterization
 of what's going to happen.
 We just want a completely different thing to happen.
 And there is where you basically have your virtual function
 staring you right in the face right there in 1960,
 contemporaneous with Lisp.
 So I'll just say, our team, yeah, I was clapping for him, too.
 I was clapping for him, too.
 Ryan, Team Fat Struct, we started in 1960 right here.
 We're like the old sort of thing at a university, like the old sort of the club, right, that's been going forever.
 We got roots, man.
 Roots, we've got hardcore stuff on our side.
 All right.
 So he throws up an example.
 He's like, hey, let's suppose we want to model a line.
 Because remember, he's working on CAD.
 He wants to be able to type in, this
 is the shape of the airplane engine.
 And out comes the engine.
 So we're trying to think about things, how do we model lines,
 how do we model surfaces, that sort of thing.
 He's like, well, one thing we could do
 is we could take the data for the line
 and we could put it in there.
 So those are like names of things and x and y
 coordinates things for like points.
 And then we could have connected up with pointers.
 So a line would have a pointer to two different points.
 And the points would point back to the line.
 And we'd make basically a winged edge data structure, right?
 I mean, these guys were off the charts
 with what they were doing.
 It's kind of crazy, but it doesn't stop there.
 So that is at the Servo Mechanisms Lab, which later
 gets renamed to Electrical Systems or something.
 It's a lab that's still around today, I believe,
 but it has a slightly different name.
 I think it might have said it was even one of the longest
 running labs.
 Anyway, so hardcore.
 But there's another MIT, it's not on the main campus
 in Cambridge.
 It's off in Lexington.
 It's called the Lincoln Laboratory, also very prominent.
 And this is the other side of a story.
 Remember I said we have this thing where
 C.A.R. Horace saying, I got these ideas from Ross.
 He was pretty cool.
 And then we also have that Alan K. part
 where he's talking about, hey, Sketchpad.
 So we haven't talked about Sketchpad.
 We found out about Ross, and he was hardcore.
 What about Sketchpad?
 How hardcore is that?
 Well, this is Ivan Sutherland.
 He's the guy who made Sketchpad, largely by himself,
 like he pretty much wrote it, again, lone wolf style.
 And he comes to the Lincoln Laboratory
 in the summer of 1960 as an intern originally.
 But he ends up doing his PhD at MIT here.
 So this is what he's doing.
 And in the course, there's these computers
 called the TX series.
 There's like TX0 and TX2.
 And they're basically made by this guy named Wes Clark.
 He's at MIT, and they're making the computers, right?
 I mean, that's the way this stuff worked back then,
 is the university actually had to make computers
 that they would use, because nobody knows what a computer
 even is yet, and they're building different versions
 of them, figuring out what the heck's going on.
 And this TX series of computers, they
 were pretty unusual, because they actually had a display.
 Like, we're back in the 1950s, right?
 So the idea that a computer was going to draw a picture for you
 that wasn't on a plotter that would draw on a piece of paper
 is completely unheard of.
 No one's doing anything like that.
 It's very rare.
 And so there's only a few places in the world
 that even have a computer that can display something.
 But the TX series of computers can.
 And this guy who was architecting them,
 that Wes Clark guy, he was very forward-thinking as well.
 And he was basically saying, I think there's something here.
 I'm going to make it so it can integrate with a light pen that
 can see what's on the CRT, and I'm
 going to have the CRT be able to display stuff
 that the computer has.
 So he makes this new computer called the TX2,
 which is an iteration of TX0.
 There's no TX1, I'm told.
 I don't know the story behind that.
 But he makes a thing called the TX2.
 And obviously, when you make something like this,
 it's hard to get time on it, because there's
 this one that was built.
 But he makes this, and it's under a thing for the Air
 Force, the US Air Force, where they don't really
 care what you do with this computer.
 They were funding it not because they
 wanted MIT to compute something for them,
 but because they wanted MIT to figure out
 what happened with large arrays of transistors for computing.
 Like, if we make big computers, what happens?
 So this is very helpful, because it
 means that the computing time on the computer
 isn't necessarily being taken up by some specific grant thing
 that they have to do.
 It's more flexible.
 So, Ivan Sutherland manages to convince Wes Clark
 that he's got this idea for being able to draw
 on the surface of the thing, make like a drawing program.
 Could he have a slot on the TX2?
 And thank god Wes Clark said yes.
 Because, from then on, Sutherland went in
 at four in the morning,
 because that was the slot that was open,
 to work on this thing.
 That's the TX2.
 And that right there is actually Sketchpad running.
 And so he would work on this.
 And I mean, when I say work on this,
 you'll notice it's not like a keyboard.
 You're not typing in code into an editor.
 It still had to be manually entered in various ways.
 There was actually a secretary who would enter some of it.
 He entered some of it.
 So it's very laborious to develop things in the 1950s,
 again, just to kind of hammer that home.
 These guys did not have much to work with.
 So he's working on this Sketchpad program.
 And what you could do with it is stuff
 that we completely take for granted today,
 as something you could just do.
 You could do things like draw lines with the light pen,
 just like we would with a mouse.
 And it's actually fairly intelligent.
 It knows things like snapping.
 Like if you go and you're going to connect back to a point,
 it knows that.
 It's not stupid, right?
 So it's not just doing random line drawing.
 It's thinking about those lines as well.
 We'll talk a little bit more about that,
 because there's a lot more to cover there.
 But Alan Kay, who I said was the person who's
 got us into this in the first place,
 the reason we're looking into it,
 he calls Sketchpad, the eventual thesis
 that Ivan Sutherland would publish on it,
 he calls it the most significant single thesis ever done.
 He says that it was like so impactful and so important,
 not just to him, but to everybody,
 and honestly, he's probably right.
 Out of Sketchpad comes a lot of research
 in computer graphics, it comes the whole
 object-oriented concept from Alan Kay,
 the whole idea of interacting with the computer
 in this way is very, very new.
 CAD, and the idea of a CAD program,
 kind of comes out of this as well.
 Now, it's so early in computing,
 I just wanna hammer home one more time,
 the kinds of things that Sutherland talks about
 if you read about his experience with Sketchfab Developing
 at the time when he published the thesis,
 no one's ever even thought about like,
 if I want to draw a line and then change where it is,
 I don't have to erase the line anymore.
 I could just move where it is.
 This is a completely new concept
 that no one's ever thought about before
 because for the rest of history,
 if you drew a line, you had to at least remove that line
 before you drew it again, right?
 So they're literally figuring out here in real time
 the kinds of paradigms that we just take
 completely for granted when you sit down
 and use a computer.
 The fact that you can move things around
 by pointing at them, completely new.
 That's what we're talking about here.
 Another example of that is rubber banding.
 They were thinking, oh, when you draw a line,
 you must have to move the light pen along the line
 to draw the line, just like you would with a T-square
 or something like that, right?
 And they were like, wait a minute.
 We could just have the light pen attach
 the end of the line and move it around
 until you got it where you want it,
 and then you could let go and that would be where it was.
 So even basic stuff like this was news to them.
 They were discovering it, right?
 So it's really, really early.
 That's how early we're talking about.
 Now, as fate would have it, when he's working on this program,
 who walks in but Mr. Douglas Ross.
 They were at separate laboratories,
 but they did talk to each other a lot.
 And the reason for that was because Ross's group
 is working on CAD.
 They're not displaying much about it, right?
 They're not working interactively,
 but they're trying to do these machined creations that
 are based on human input.
 So because Sutherland's pretty new to this stuff,
 he talks to Ross and he's like,
 how do I make stuff like lines?
 How do I do that kind of data modeling in the computer?
 Do you guys have ideas?
 And Douglas Ross is like, have I got an idea for you?
 It's called a Plex, right?
 And as we saw, a Plex is pretty awesome.
 And Ivan Sutherland is probably one of the smartest people
 on planet Earth, so he recognizes right away
 this is a good idea too.
 So he's like, all right, we're doing it, right?
 He says, what I'm going to be making this program to do
 is have a bunch of primitives, like I've
 got lines and things like that that I'm going to create.
 And I don't have that many types of things.
 I'm just going to have lines.
 And later, actually, it was Claude Shannon,
 the father of information theory,
 who says you should put circles in it, too.
 So there's all these kind of little answers.
 If you actually go read this yourself,
 you'll find there's so many things
 I couldn't fit in this lecture because it would have been
 like eight hours.
 But anyway, so he's saying we're going
 to have all these instances of things, lots of lines
 and stuff like that.
 So I don't really need anything more
 than just this end component thing,
 and I'll just have lots of those,
 and that's how we'll do it.
 This is how I'm gonna write the program.
 And here's his diagram from his thesis
 about how he's going to structure, right,
 or how he did structure lines and points, right?
 And there's some information missing from this,
 because, you know, I mean,
 if you're sketching things in Sketchpad
 with that light pen and it's very slow, right,
 it's not, he can't make slides with software
 like we have today.
 Not that the software I used to make the slides
 was particularly better than Sketchpad,
 but you get the idea.
 So it's not completely documented in here,
 but you can see here it's got the line,
 it's got a pointer to each of the points and so on
 in accordance with sort of sketching that out.
 And hey, it's exactly like that paper from Doug Ross, right?
 And Doug Ross published this in 1960,
 so Ross and his team were already thinking
 along these lines before Sutherland even got to the lab,
 right, and started working on Sketchpad
 in the later, a little bit later in the early 60s.
 So that's how this whole thing ties together.
 Ross and Sutherland are having a huge party here,
 and it's awesome.
 And if you remember, we had these things in the Plex that
 were basically like jumps, right?
 They were like subroutines.
 They were the virtual functions of the time,
 or we maybe would call them not so virtual functions.
 Well, you could implement that way.
 We just called them function pointers, right?
 And you can do all the same things
 you can do with a function pointer.
 That was something that Doug Ross was talking about
 in his Plexes in the original paper,
 and it's right there in Sketchpad as well.
 This is how he did things like, I
 want to go ahead and draw this shape,
 but I don't want to bother having
 actual different data types be completely specialized,
 having the routines completely specialized.
 So what I'll do is I'll just have
 a few entries in the data type that say, how will I display it?
 What would I jump to display it to figure out how big it was
 or to move it?
 So again, virtual functions right there.
 They come from the plexus.
 He puts it in, and that is how he actually
 implemented that kind of parametric behavior
 in this program, in Sketchpad.
 Now, because we've already got one applause line
 before for this kind of thing, I'll just point out,
 there's empty space in between these things here.
 And on the previous one, I was like,
 well, the reason that there's empty space on those
 is because we probably didn't have time to draw it out.
 And that was true for that diagram,
 because I know more about the data structure
 because I've spent way too much time looking at this program.
 But in this one, those are actually space in the struct.
 Those fields there, there's gaps.
 So why are there gaps?
 Why are there gaps in this thing?
 And I wanted to know, so I'm combing through this.
 This is like, what are the gaps about?
 Is it just the same as the other one,
 where it was like you just didn't draw it in there
 or something?
 What are the gaps about?
 I found it.
 At present, all generic blocks still
 carry space for all the information in any of them
 simply because of historical reasons.
 This accounts for the spaces seen in figure 3-7.
 What this means is Sketchpad is on Team Fatstruck, right?
 In 1963, he was still doing the same thing
 that the Plex was doing.
 He was just saying, look, I don't really
 maybe I should have gone back and tried
 to figure out some way to compact these.
 But you know what?
 We didn't end up doing that.
 And so he kind of just has that mention there.
 It's like, yep, all of them are the same size,
 and we just leave those fields out
 if they weren't going to be there, right?
 So I'm bending it a little bit there,
 because in the Sketchfab paper, it's
 very hard to tell exactly the way,
 because he doesn't give explicit data layouts for a lot
 of things.
 It's hard to tell whether or not he was using things that always
 had fat struct, or whether it was more
 like semi-discriminated unions, so there
 were pairs of things that would have been used differently.
 So it's either team fat struct or team overlay fat struct,
 but it's one or the other.
 All right, so we've come to the part where we can build our tree.
 As far as I can tell, it doesn't go any deeper than this.
 This is where it actually started for reals this time.
 Doug Ross and his team, this idea of plexes.
 It goes to Ivan Sutherland because he works there,
 and he asks us for their advice on how
 to build the stuff in Sketchpad, and he picks up the plex
 concept.
 It also goes to CAR Horror.
 That plex concept goes to him because they sit on the ALOL
 committee together.
 So that's our first branch.
 We then have that horror paper was read by Dahl and Nygaard,
 who decide to use it to create their Simula class idea.
 And both of those, the Simula and Sketchpad,
 influence Alan Kay to create the Smalltalk branch of OOP.
 Meanwhile, the experience with Simula
 influences Bjorn Stroustrup to create C with classes,
 and then C++.
 Now, by the way, this is an inheritance hierarchy
 that matches the domain model.
 But there's a fun part of it.
 Some of you may know this, some of you may not, because, I mean,
 why would you?
 Obviously, we know C++ has multiple inheritance.
 It got multiple inheritance not right away,
 but it got it eventually.
 Smalltalk never did.
 Single inheritance.
 However, single inheritance will get you C++.
 but it won't get you small talk.
 You need two parents, right?
 What can I say?
 So that's the actual end.
 Now we've built our tree, we're finally done,
 we know where this stuff came from, whew, right?
 It was long.
 Of course, there is a personal angle to this as well,
 so I should probably say
 that the reason I decided to go do all this,
 it probably wouldn't be, you know,
 I'm on that thing called the internet all the time.
 And most of the time, I'm just gonna post something snide
 as a reply and not think about it again.
 So why did I actually go and do all this research
 just for this?
 Why didn't I just say, who cares about these things?
 I don't use those compile time hierarchies
 and just post something mean on Twitter.
 Why didn't I do that this time?
 It would have saved me a lot of time.
 Of course, I wouldn't have had anything to present today,
 but it would have saved me a lot of time.
 Well, here's why.
 Back in 1997, which by the way is right around
 the same time that we started this talk, right?
 The Looking Glass stuff that they did
 with Entity Component Systems was 1998,
 which means they would have been working on it in 1997.
 It would have been up and running at that time,
 so it's right at the same time.
 I'm working with a fellow called Chris Hecker,
 And I'm brand new.
 I am literally out of high school.
 So I don't know anything.
 I programmed a ton as a kid.
 But if you asked me my thoughts on computer architecture
 or something like that, I obviously
 would have answered very confidently
 and been completely wrong about everything.
 So he says, we're going to need a level editor.
 This is basically a game that we're working on.
 We need a level editor that does CSG on spheres.
 So the idea was you take these spheres
 and you build a level up out of unioning them together,
 like a standard CSG modeling kind of stuff.
 But of course, I don't really know any CSG stuff.
 I really know how to do that.
 So I go using, I think it was Sightseer at the time.
 Nowadays you might use Google Scholar or something
 to search for papers.
 So I go to use Sightseer, I think was up at the time,
 or maybe there was a precursor to it,
 and I can't remember the actual one,
 but there were things at the time, even then, this early,
 because the internet's only been available to the public
 for a short time, really.
 Like it was ARPANET until the mid-90s, right?
 So when we're looking at this, I go to crawl papers
 and I'm like, okay, CSGN spheres,
 like to try to type some things in,
 read some papers, what am I gonna do?
 And I come across this thing called alpha shapes.
 And alpha shapes are just the name
 that someone in a paper had given to something
 that was basically implicit services.
 I don't really know why they call it alpha shapes
 because it escapes me now.
 I'm sure I knew at the time
 because I had just read the paper,
 but for somebody that were talking about these alpha shapes,
 I looked at them and was like, oh, it's like spheres,
 But when you move them together, they
 make this nice, smooth joint.
 They don't make that hard edge.
 And I was thinking, oh, for levels,
 that would be really cool.
 That might be way better than if we did CSG on spheres,
 because it would have this really cool effect.
 So it was going to be on the inside of these things, which
 are typically called metaballs.
 And it was going to be the negative space
 of the metaballs.
 So I made a modeler for this, and I
 called it MegaMan, which has nothing
 to do with MegaMan, completely legalistic from that.
 It's kind of changed one letter, and maybe it's the same.
 But nothing to do with this.
 It's just negative space metaballs.
 And this is what it looked like.
 And effectively, what you did is you picked things in it.
 You can see those spheres there are metaballs.
 They're the kind of spheres you put together.
 And they form these kind of surfaces.
 And we're seeing the inside of what you're creating, right,
 because it's a negative space.
 So that's why it looks kind of weird.
 You would normally see the outside in a metaball modeler.
 But this is what I was working on.
 Well, I mean, and it's finished.
 You can use it.
 I still have it to this day, you can model stuff around.
 It's pretty janky, but it does what it's supposed to do.
 And so the way that you interacted with it
 is you picked those spheres and you could move them around
 by dragging the mouse and that sort of stuff.
 The same sort of things that Sketchpad was doing,
 only with much better hardware and much more advantages
 in terms of development, same kind of idea
 because Sutherland was so far ahead.
 And so if you wanted to create stuff,
 you might select things like here,
 I don't know if you can see it,
 I've selected those two meta balls at the top,
 and then I've just like, there's a thing
 you could like rapidly stamp them down,
 I kind of just drag them, like stamp, stamp, stamp, stamp,
 and you can create more of the level,
 just kind of like blobbing things together.
 So it was a selection-based UI, like most programs are,
 where I select a bunch of things,
 and then I wanted the program to basically
 have a nice architecture for being able to do that,
 and then present the user with the user interface
 that would be appropriate for that selection.
 And this is actually a really hard architecture problem
 if you're not experienced, which I wasn't.
 Because it's like, well, if what you've been told
 is that you make these hierarchies,
 like these class hierarchies and things like that,
 and what we're really saying is,
 I'm gonna select all these things
 that are really derived types of things,
 but now I want this higher level thinking thing
 to look across everything that you've selected
 and come up with a plan for what the unified interaction
 would be across those things.
 And then when you actually wanna do the interaction,
 it's gotta make sense for what's going on.
 And this is really tricky, because the Inheritance Hierarchy
 thing doesn't help you at all for this.
 It fights you.
 You're constantly like, oh, do I just
 add a bunch of functions to the base class that's
 anything you might want to do to a class?
 You basically fatty struct your interface,
 but leave the hierarchy in place.
 There's all these things you might think to do,
 and they just don't work very well.
 But I was pretty gung ho at the time.
 I'm not old like I am now.
 So at the time, I don't mind typing a lot.
 So I go to town on this.
 I'm like, all right, I'm going to try
 to figure out how to do this cleanly, quote unquote,
 and we end up with crap like this.
 Now a lot of times I try to convince people.
 I'm like, look, everyone thinks that I was
 like some C-only programmer.
 I just don't know anything about like huge, crazy, hairy,
 object-oriented programming or anything like that.
 It's just like you don't understand.
 It's like, no, dude, I wrote some of the most ridiculous
 oops stuff you have ever seen when I was, like, 20.
 I was doing crap like this all the time.
 It was awful.
 I'm not proud of it.
 But here is what's going on, right?
 So the way I chose to solve this problem,
 never mind the fact that I'm doing the implementation
 inheritance thing up there with a template on the class.
 Have you ever seen this trick?
 It's an old school.
 So it's like, there's so much stuff in this code base,
 you would, it's a nightmare.
 But anyway, so if you look at what's going on here,
 I have get and set functions like you're supposed to have
 on any proper object.
 And you can get the center, you can set the center,
 that sort of thing, get the service radius,
 set the service radius, right?
 And now what I want to do is I want to have some way
 that these can be interacted with in a unified way.
 So what do I do?
 Anytime you create one of these things,
 I build a parallel structure.
 I create a property list that basically is callbacks
 using, this is called a rich hickey functor.
 I'm not kidding.
 It was a callback that you could use
 to do type-safe callbacks back in the early days of C++.
 I'm trying to tell you, where's the camera?
 Seriously, I have done ridiculous OOP stuff.
 If you don't believe me after seeing this,
 I do not know what to tell you.
 We can post more of this code if we need to.
 So anyway, so basically, when it's created,
 it creates a parallel hierarchy that's just,
 it's not actually the properties.
 It's just callbacks that would get and set the properties.
 And then, this is what that class looked like.
 Here's the get and set callbacks abstracted into a property.
 And then, if you wanted to use it,
 you could loop over the properties.
 You could create a modification that
 was typed on the property to do the changes you actually
 wanted to do.
 OK, and that's the support like dragging and undo
 and things like that.
 So this is what it looked like if you drew it out.
 I have a metaball with a radius and center.
 The data's in the metaball, just like a good object-oriented
 programming thing would tell you to do.
 It's encapsulated inside the metaball.
 I create parallel, I call them property universes.
 I create property universes, all of the center properties,
 all of the radius properties, and they
 are callbacks to modify or retrieve
 the data in the actual entity here, right, the meta ball.
 And then when you interact with it,
 you use modifications to interact.
 And this way, when I wrote the code,
 I could think about things in terms of the center
 or in terms of the radius.
 So what I'd do is when you multi-selected,
 I'd go, what are all the property types that you've had?
 And I'll just make interactions that
 work with those property types.
 And I'll put up little UI elements
 that work with those property types.
 If the diagram looks familiar to you,
 it's because you have a good memory,
 because this talk is very long.
 If I had a brain, I would have realized you don't need that.
 Just put the properties in the actual universes themselves
 and use an ID for lookup, and it's an entity component
 system.
 It's the same architecture.
 It's just I sucked at it, and Looking Glass was good.
 That's the difference, right?
 So anyway, this was the slide I showed at the beginning.
 This is the slide that I did.
 You see what I'm talking about, right?
 My bad, right?
 This was my bad.
 I screwed up.
 I say that I don't blame myself because I was a kid, but really, I mean, I should have
 thought it through.
 So anyway, in 2024, when I was accidentally on the internet
 like I should not have been, I'm thinking to myself,
 how the heck did Sketchpad do this anyway?
 Because they must have had the same problems that I had,
 because he could do all this stuff.
 It wasn't just a shape drawing program.
 I withheld some information from you
 if you've never seen Sketchpad before.
 I apologize.
 It's for dramatic effect.
 worth it, trust me.
 It could do a lot of other stuff than just draw.
 The just drawing stuff is the stuff
 that Adobe copied or things like that,
 because that was the part that they could understand.
 The hardcore stuff, only Sutherland knows how to do.
 And here's what that looks like.
 You could say I want these lines to be
 perpendicular to each other, and it would do it.
 You could take a drawing like this
 and pick a point that's not even a point.
 It's the intersection of two lines.
 And not just snap, but say, I want this radius from now on
 to always have its center point, like the circle arc,
 it's going to be drawn around that intersection.
 And not for snapping, but for always.
 So that if I then go do some constraints on this thing,
 which Sutherland's about to do, he's
 going to say make that perpendicular to that,
 perpendicular to that, perpendicular to that, which
 you can't do in anything from Adobe.
 You have to go get AutoCAD or something for this.
 And by the way, AutoCAD didn't add it till like 2007
 or something like this.
 They didn't have it in AutoCAD.
 When you tell it those things, you say, OK,
 that's what I want my shape to be.
 It'll just solve it for you.
 And if you move it, move the points around,
 it'll solve it again into whatever the closest shape is,
 using like a relaxation least squares kind of thing.
 And I'm like, what the heck?
 I remember this, because I'd seen this demo before.
 And I'm sitting there thinking, you
 know, that whole compile time hierarchy thing,
 and Alan Case, he saw a sketch pad.
 So I'd known those parts, all the details
 I had to learn for this talk.
 But I'm like, what the heck did he do?
 He's working on this crap computer.
 I get that he's way smarter than me, so fair enough.
 But he still had to do something, right?
 So what did he do?
 What does a really smart person do
 when they're faced with this situation?
 Because he's creating stuff that people
 who came after him, who have crazy debuggers and WYSIWYG
 editing and the ability to run things quickly and iterate,
 they don't have to go in at 4 in the morning
 and enter things manually into a computer.
 How did he do it?
 Because no one did it afterwards for decades.
 So let's take a look.
 If we go in and we look at how he represented
 constraints.
 He represented constraints by saying,
 there's going to be variables that are constrained.
 So I'm going to have some variables.
 Things like this point or this line, that sort of thing,
 would be considered a variable in the system, something
 that is like a very primitive element of the system.
 So it could do that.
 You'd pick those, and then you would
 have a certain type of the constraint,
 essentially, which is like, what am I actually
 going to be doing with this particular constraint?
 But they're relatively generic in this way.
 And then the things you could constrain, scalars, points,
 instances, text, digits, and dummies,
 these are the different things you could constrain.
 They're sort of all, again, almost team fat struct there.
 They're kind of like all things you can reference
 as a variable without needing to know
 which one you're looking at.
 And so you can remember when we were talking about
 here's how those lines and points are,
 the line would not necessarily be something
 that was constrained, right?
 Because it's a bigger thing than these are.
 But the points would potentially be something
 that was constrained, right?
 So you might say things about them in that way.
 And I don't know all the specifics
 of how the constraints work,
 because he doesn't publish,
 like in the thesis it only talks about to a limited degree.
 So I can't give you a perfect breakdown
 of exactly every piece of the system,
 but I mined as much out of it as I could.
 And he goes on to talk about how this thing was architected
 so that he could solve things.
 He said, the ring structure,
 which we have not looked at yet,
 was designed to permit rapid constraint satisfaction.
 So what is this ring structure?
 What does he mean by that?
 But he's pinning it on that.
 He's saying the ring structure was really important,
 and that's what's letting us do this stuff.
 He also says, all references made to a particular end
 component element or block are collected together
 by a string of pointers which are written
 to that block, which is kind of a type of ring structure.
 And he says, this, which really throws you for a loop
 when you're first reading this thesis, in the data storage
 the separation of general and specific
 is accomplished by collecting all things of one type
 together as chickens, which belong to a generic hen.
 Now I will save you the trouble, those of you
 who want to read this thesis, about what those mean.
 A hen is a sentinel of a linked list.
 A chicken is a link in a linked list
 that points back to the Sentinel, essentially.
 So here is how the data is laid out.
 Type is a chicken.
 Link, quote unquote.
 Spec B is a hen.
 So now when we go back to this type
 that we've already looked at, we can see them up there
 at the top.
 Type is the chicken.
 Spec B is the hen.
 This is sort of the workhorse of the structural elements
 of this system.
 And the way that it works is that chicken at the top
 links it into a giant linked list
 with all of its siblings at its level of whatever it's doing.
 And the spec b hen is the sentinel
 for the list of all the things that are subordinate
 to this thing.
 So it's like an up and down kind of a thing
 that's going on there.
 So chicken and hen.
 Here is how he actually draws it.
 You can see it's just a linked list, exactly like we expect.
 Key or hen threw me for a long time until I got it.
 Key or hen just means hen.
 For some reason, in the paper, he has,
 he never says what a key is until this one part
 where he's like, sometimes I also call a hen a key.
 So anyway, okay.
 He then goes on to present this.
 And this is the runtime structure of Sketchpad.
 You start with a universe, and it has a sentinel, or hen, right?
 It has a sentinel that has a ring inside of which is variables, holders, constraints, and topos.
 Again, not a compile-time hierarchy, actually a runtime set of rings, right?
 So this is not baked into the compilation of this program in any particular way.
 It's just how the rings are structured at runtime when they are built.
 There are variables, holders, constraints, and topos, the ones we care about in this case.
 We don't really care about the holders much for understanding,
 But the topos, the line circles and pictures,
 pictures are just like copies of things,
 like copies of other drawings, right?
 So the topos are the things that we're actually
 sort of the users interacting with at a higher level.
 The variables sometimes, like they see points
 and things like that, or text things they can edit.
 The topos are made up of those variables, right?
 A line is made up of points.
 And then the constraints are things that you apply to them.
 Now it's important to notice,
 this is sort of, you could say,
 the opposite of encapsulation.
 What this structure implies is that at any time,
 any part of the system can go looking at anything.
 It's almost like a complete introspection system
 for what's going on.
 A topo, for example, that is a line
 is not encapsulated at all.
 The two points that make it up are just
 floating in the breeze over there that you can go just grab.
 And you can do whatever you want to those points
 without that thing even knowing that it happened.
 So it's almost like the most unencapsulated thing
 that you could possibly imagine, which is probably
 why it was so cool.
 But if we draw it, it kind of looks like this.
 The topos, you have a circle, it's got a radius and a center.
 It has pointers out to those actual things,
 which we call variables.
 Those are the scalars, those are the points.
 And if we have something like constraints
 operate on them, it just points into those things.
 And all of these pointers are typically bidirectional.
 That ring structure is allowing you to walk in both directions
 if you want to.
 But this is the way that you're actually conceptualizing
 the link in those cases.
 Once again, the same diagram, more or less,
 than what I had to write, which is the same diagram more or less
 than an entity component system is,
 because you are able to iterate over all of the properties
 you want to work with, which lets you implement things
 like a constraint, or in my case, a modification,
 in this generic way that operates
 on the pieces of things or components in any component
 system language in a way that doesn't require
 this sort of weird abstraction thought
 where you're trying to figure out
 how to get things out of something
 in order to work on them.
 That was in 1963.
 So, to a first approximation, Ivan Sutherland was at the same level of closeness to an anti-component
 system in 1963 as I was in 1997.
 And then people from there didn't notice.
 That's the only thing I can figure out.
 I have not found anything except for one quote that I'll show you
 that explains why the heck no one realized how important this was.
 They didn't think about the fact that the power of this system
 is coming from the fact that you can look at these components of things
 and architect around that instead of architecting around the bag,
 which who cares?
 Again, still object-oriented in its thinking,
 You don't have to claim it's not OOP.
 It can still be OOP.
 It's just where are those encapsulation boundaries?
 Where are the boundaries, right?
 Instead of looking at it and going,
 oh, the important place to put the boundary was around this.
 That's where the power is coming from.
 They're looking over here.
 They're like, the power of this system was that.
 The ability to have virtual functions on it, right?
 The ability to say, if I want to draw this a different way,
 I change the subroutine.
 Now, I'm not trying to say that isn't useful.
 It's function pointers are good in certain circumstances, but what inevitably happens is
 They're only gonna get you the simple stuff
 The only reason that even worked for Sutherland in the display case is because his display was simple
 He didn't have to do things like intersecting stuff for hidden line removal or doing some kind of calling on it or who knows what?
 So he could just have an abstract display function because it never interacted with any other part of the system
 It's the least interesting part of this architecture
 Yes, it's cool. It's Doug T. Ross's idea about plexes. It's where it comes from, right? And that
 was a great idea, and we should keep it, but it's not the cool part of Sketchpad at all, right?
 It's the most trivial part of it. So that is the 35-year mistake. Oops, right? We had the answer.
 We could have been so far ahead if we just studied that and figured that out, because it's so much
 more powerful to think about systems that way, especially the hardest kinds of systems
 like editors. This is the quote I was talking about. So, you can see here, this is Alan
 Kay, father of Smalltalk, and this quote breaks my heart because I like Alan Kay. I think
 everyone likes Alan Kay. Probably, I don't know, maybe not. There's probably someone
 out there who hates Alan Kay. Alan Kay is very, he's trying all kinds of cool things.
 Xerox PARC is awesome.
 I'm not gonna say something negative about Alan Kay.
 I'm just not gonna do it.
 This quote breaks my heart because what he says
 in this quote is basically that the constraint solver,
 which he obviously knew about, so he,
 because I happen to know that Alan Kay read the thesis.
 That's documented, Alan Kay says he read the thesis.
 And he paid attention to the constraint solver part.
 And he paid attention to it enough to know
 that what he called it omniscient.
 He was calling it omniscient, right?
 This idea that it could look at the properties like that
 and work on them.
 And Kay thinks it's a bad thing, right?
 He says, hey, there's this thing called Allen-Borning's Thing
 Lab, which is another program that was made later,
 a first-team attempt to go beyond such-and-such.
 And he devised a nice approach for dealing
 with constraints that didn't require the solver
 to be omniscient.
 The omniscient part was the good part, right?
 That was the thing that was so powerful.
 It's why it's kind of torturous to make things in small talk.
 I have dabbled in it a little bit.
 It's like, no, the encapsulation needs
 to be in the right place.
 You don't want to think of everything
 as these small, little objects.
 So why did they?
 Why was Alan Kaso focused on that stuff?
 Why was Strewstrup's show focused on that stuff?
 And honestly, from reading it, this is my best guess.
 Their backgrounds predisposed them not to want this, right?
 You look at where they come from,
 Strucif comes from distributed systems.
 Alan Kay had a degree in molecular biology.
 They're both 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 they're certain, Alan Kay especially,
 that that is the future of how we will engineer things.
 They're going to be like microorganisms,
 where they're little things that we instance, right?
 And they just talk to each other.
 So everything will be built that way from the ground up.
 But the problem with that is,
 it doesn't seem to work in practice.
 It's a great idea when thinking about systems
 that are actually separated in that way,
 like actual computers talking over a network,
 it makes perfect sense,
 because they do look like microorganisms.
 And most of Alan Kay's ideas actually
 map very well to things like the internet writ large,
 where you really do have to just pass messages back and forth.
 So again, not going to say something negative about Alan
 Kay.
 The ideas are good, and they do have very good applications.
 It's smart.
 It really is.
 But when you're talking about code
 that's working inside one computer in the same core
 memory that's meant to work together, it's too limiting.
 It's way too limiting.
 It's not the right model, and it forces
 is to do way too much work to accomplish the same thing.
 So just to underscore, reading this history
 actually gave me a nice perspective on these things.
 And I think there's reasons why C++ was adopted,
 even after all the stuff I just said
 about how the compile time stuff wasn't very good.
 One of the things that I didn't really appreciate
 was it kind of sounds to me like Shrewstip was really
 important in getting type checking for us.
 Like, C did not even type check function calls
 at the time the was making C with classes.
 And he recognized, because of his background in Simula,
 he's like, this is ridiculous.
 I think he gave an example like, if I do square root,
 like SQRT in C, parentheses 2, that doesn't work right now.
 Because it passes the integer 2, and it
 doesn't check that square root's taken a double or something,
 or whatever it was taking in that particular version
 of the library he was using.
 He's like, that cannot be something
 that we have to catch at runtime,
 especially not in those days when debuggers are worse
 and everything is worse, right?
 Iteration time is slower.
 So you get this situation where you're like,
 I kind of see why these things took off.
 Some of these things, like the compile time encapsulation
 hierarchies, they're coming in at the same time
 that C++ is making positive contributions that actually
 do help you program for real, right?
 And it's not like we can't think
 of uses for things like virtual function in classes.
 interfaces, just that bare concept, is a place where we still use those things today, even
 new languages, those things. So there is that, too, if it's used responsibly, right? It's
 just that compile-time hierarchy that was a problem. And this is a quote that I also
 want to include just to give Shrewsworth credit. He's also on the same team. He wants the fast
 thing, right, to be easy for people to do. You don't want your definition of good code
 to be slow, right?
 So anyway, when you read through all this stuff,
 you're kind of rooting for everybody,
 to be completely honest.
 Even after all the suffering that C++ has caused me
 in my life, I was kind of like, oh, all right, I get it.
 I get it, man, I do.
 So that's the 35-year mistake.
 It's the distance between those two years.
 The year in which we could have had
 the Entity Component System,
 because the first person has sort of done something
 that was almost that, and the year in which we actually got
 the Entity Component System, which I'm not even saying
 is a good design or not.
 I don't even have an opinion on something like that,
 to be completely honest with you.
 But I think it was a really cool idea
 and an interesting architectural idea to explore.
 And so I'm really glad that we got there either way.
 But I wish we could have gotten there a little bit sooner.
 So unfortunately, the mistake, if that's 35 years,
 it does unfortunately not end there.
 Because if you do a search on Google right now,
 and you're like, I need an OOP tutorial.
 I need an object-oriented programming tutorial.
 What will you see?
 Hit number one, we'll have a domain model
 that has encapsulation that matches,
 or sorry, you'll have a compile time hierarchy
 that matches the domain model exactly like we don't want.
 This person imagines, this is the number one hit.
 He imagines something called a special Iron Man
 that's slightly different from a regular Iron Man
 because I guess in his mind, or whoever wrote it,
 I don't even know, it might be a team of people,
 there's some kind of a specialized Iron Man
 that I didn't, I mean I don't read comics,
 maybe that's a thing.
 Hit number two, Java OOP, this is from W3Schools.
 Again, not only is it a compile-time hierarchy that
 matches the domain model, but it's one of the ones
 that you can actually find in those early papers.
 Shrewsup talks about vehicles sending cars.
 And if you remember, cars crossing a bridge,
 it could be trucks or buses, was in Simula day one.
 It's where they came up with that subclassing thing
 that they were going to do.
 So we're still pushing it today on hit number two.
 Hit number three is three types of bicycle
 that come off a bicycle, right?
 Ugh!
 And don't ask me why there are spaces in that
 and not in the mountain, but I mean, I don't even know.
 That's the top three hits.
 I stopped looking after that, because I'm just like,
 I give up.
 So one thing that we could do to keep this mistake
 from propagating is just get this idea out there
 that compile-time hierarchies of encapsulation that match
 the domain model are not that good.
 Sometimes they work, like with distributed systems,
 or maybe microbiology.
 But a lot of times, they're just more work than they're worth.
 And that would help.
 It would help a lot.
 And I would bolster that here at finally the end of the talk
 with this quote, which I think is the best one to end on.
 It's that the most treacherous metaphors are the ones that
 seem to work for a time because they
 can keep more powerful insights from bubbling up.
 We got this thing in place.
 It was this compile-time hierarchy
 that matched the domain model idea.
 And it was stopping all of our other architectural development
 because everyone was saying it was going to work,
 and it was going to be great.
 And we just must be doing it wrong, right?
 But actually, that wasn't the case.
 And this is a hard quote to find.
 If you search for it, I'm not sure if you will find it.
 But if you read through, you will find it.
 It comes from Alan Kay.
 He's the one who said it, right?
 That's him sitting at his, you know,
 I think that must be one of the original Palo Alto computers,
 right?
 The Alto, I think is what that one is, from Xerox PARC.
 So that's the actual end of my talk.
 Thanks, everyone, for listening.
 I'm surprised I was able to remember
 all of that stuff for this.
 You've been a wonderful audience.
 And I guess, now, Ryan Fleury will
 be coming up on stage to interview me and take
 questions from the audience.
 Is this correct?
 Sam?
 What?
 SAM TSE-CHIEN PAN- Sam, is that true?
 the organizer ladies and gentlemen
 please welcome to the stage ryan flurry everyone
 okay well yeah thank you for that talk that was really good it was a lot of fun putting together
 yeah so um i guess the first comment that i would have is that it seems like uh i'm a little bit
 glad to see that people in the six there's two things i'm glad to see that people in the 60s were
 like using these techniques that seem to be re-emergent it kind of makes it feel like
 there's like uh maybe like some degree of gas lighting since then like there's like all these
 you rediscover these things they seem to be useful um and then for some reason like uh
 we haven't actually that information has been lost i guess do do you find i mean i assume you find
 the same thing to be true yeah i mean i i guess the problem so i don't even know if it's like
 gaslighting in that sense right because it's like i don't necessarily know i didn't find a lot of
 evidence that people were like intentionally obviously like it wasn't like somebody was
 like i would rather promote my thing than this thing in sketchpad that i noticed that quote from
 alan k is kind of instructive in this case he honestly believed that having the thing be
 omniscient was bad he's saying that this is bad right and you see the same thing from strewship
 saying that this you know switch you know this basic switch on a type is bad and so i i think
 they just honestly believe that they they believe that these were bad for modularity and in their
 minds, because they're so focused on the modularity, they were just saying, this isn't good. And
 so it just kind of doesn't get propagated. This is the thing that you see all the time,
 right? If someone isn't a good PR, isn't good PR for their thing, it doesn't get propagated.
 Yeah, that makes sense. So in your own personal programming, like, journey, you started with,
 like, learning the traditional object-oriented sort of, or, like, C++ templatization of compile
 time hierarchies of encapsulation and so on you uh i mean i i have an idea of where you change or
 where you developed but i'm curious about where you learned to not do that and furthermore from
 where you learned it where did they learn not to do it did they did they learn from the original
 papers or did the simple ideas just reemerge or what what is the story there uh so that's kind
 kind of interesting so when I was younger like so when I started programming when I was very little
 right I didn't know any of the things I wouldn't know anything about architecture C++ wasn't even
 invented uh and I don't think would have been invented so C so C with classes would have been
 but C++ wasn't even like out in the world the time when I would have started in like basic or
 something like that right so I definitely uh started without any of these notions but then
 when I first went out into like you know professional I mean my first job was
 hardly professional but when I went out into the world of like commercial
 programming I I definitely like thought that everyone was gonna be right about
 this I just didn't know and so I tried programming in this model and learned
 all those things because you know it kind of has a Magic the Gathering feel
 to it it's like you're learning a lot of intricacy and it's just magic gathering
 it's something people made up that was fictional but you know you don't know
 that you think it's real right but you're getting into it in the same way you might get into magic
 gathering like oh i figured out the template can do this thing and it becomes its own little game
 right so i think it kind of went that way for me and at the time it was very obvious that this was
 stupid like if i'd actually thought about it but i chalked it up to me just not knowing how to do
 it right which i don't think was actually true i think it was just like no this is actually just
 worse than what you're doing because what i noticed was things that would have taken me only
 a few days before were taking like months to like figure out all of the ways that i would have to do
 it in order to make it fit these things. And I think I was just too stupid to realize that
 probably just means it's just a bad approach, right? So you had a second part of the question,
 which was, how did I undo it? That part is a little more concerning, I guess, because the
 only reason that happened was I happened to then program with people who had never done that. So
 there were people who never had the experience of being told to do this architecture or just
 ignored it and continued to program the old school way. And I was like, oh, these people
 are very successful and very important programmers so maybe it's not the case that i just don't
 understand it maybe there's actually something to keep doing this way the reason that's more
 concerning to me is it's like it means if those people aren't around if they weren't around maybe
 i would never have that experience right and so you kind of need this generational overlap of
 people who still remember the good things about the previous way to tell you that the new way
 kind of sucks right and do you know like um when you worked with those other programmers
 were they were they informed by this older generation like the 1960s papers of
 how they were doing these things did they just take those lessons or
 no i think it's just a case of like the
 if you were using programming resources from that era of even just the 1970s
 you wouldn't be seeing like it was more academic the places where oop would have been talked about
 right small talk was a thing that would have been in research stuff right and
 similar was a thing with papers and stuff like that but the person who
 learns to program like you know in the game industry and something that the
 person who learns to program on an Apple to is not being exposed to those things
 right so they just learned in an environment and using reference
 materials that did presumably kind of come through that culture but it wasn't
 like they were you nobody was like oh yeah Doug T Ross man and flexes like
 that's that's the stuff right it's like no like so I think it's just more that
 they hadn't have had that idea pushed down on them
 in a way that they believed.
 So, I had it in my head,
 but I gotta check my notes here.
 So I think that, I was curious about,
 I have a collection of like,
 not exactly related questions or discussions.
 Hit me.
 So one of the things, you introduced this subject
 by saying like, one of the arguments that people
 will use to promote sort of object-oriented these,
 or I shouldn't say object-oriented,
 I should say compile-time hierarchies.
 If someone out there wants to come up
 with a catchy moniker for that, it is hard to say.
 So we need something like OOP for that, right?
 And it would be nice, because again, like I said,
 I think it's pretty important to draw that distinction,
 because like Mok, who I quoted at the beginning of the thing,
 who did that entity component system,
 he's thinking of it in terms of object-oriented.
 He's not thinking this is not object-oriented, right?
 So you can still, you can easily call yourself
 an object-oriented programmer,
 and want object-oriented principles
 to apply to your code base,
 and just not think about that compile time thing.
 And it seems to work pretty well.
 Yeah, it kind of seemed like
 the object-oriented part of drawing boundaries,
 it doesn't actually, it's not,
 it might be descriptive of a system,
 but it's not prescribing
 where to put those boundaries exactly.
 Yes, exactly.
 And also, furthermore,
 it's something I think we could all agree about, right?
 I don't know that a hardcore object-oriented person,
 like certainly not Alan Kay probably,
 would never agree that making like an API boundary
 around something was that object-oriented
 if the thing was fairly large, although he might.
 But we can all agree that that's a thing we want to do.
 Like, I don't consider myself an object-oriented programmer,
 but I consider that to be a good thing to do,
 and I think that's certainly a point of commonality.
 And I think most object-oriented programmers
 would call that an object-oriented thing to do,
 even though it really predates that.
 you could just think of object oriented programming.
 One of the principles is sort of crystallizing that idea
 into one of their core concepts.
 And I think that's a good core tenant to have, right?
 To do that at the appropriate size.
 That's where I tend to part ways.
 It's like what that size is.
 So on the large team subject,
 you were digging through all of these historical papers
 and records and everything.
 Did you actually find any research
 about what people actually do for large teams?
 So one of the things is I was focused
 on figuring out where these ideas came from.
 So I didn't go looking for where the, I don't want to call them excuses, it's too disparaging,
 but where the justifications came from, right?
 So what I can tell you, so I don't know, that's another, that'd be a whole other topic.
 This thing took two hours or something like that, right?
 So that's a whole other question.
 It would be very interesting to answer.
 But what I can tell you is during the course of the development of these core ideas,
 I never once saw anyone talk about that.
 and they were always like one person doing a team,
 doing a thing by themselves,
 or two people developing things by themselves.
 And to the extent that like larger teams
 would have been involved at all,
 it might have been on the Simula side.
 Like some of their opinions may have been influenced by,
 you know, in ways that they didn't directly,
 like they didn't attribute any of those things to it,
 but maybe they were seeing people use Simula
 out in the world that had something to do with it.
 But I don't think there were that large teams
 working on Simula either, I don't know.
 Yeah, it's kind of interesting alone
 that the history of computing,
 it's always large teams or small teams
 pushing large improvements like successively.
 So it's interesting to optimize for large teams in that way.
 Well, and you might even say it creates a bit of a problem
 because it means that like,
 if the innovation happens in small teams,
 but we do need large teams of people to do certain things,
 it's like, it's kind of hard to figure out
 where the innovation in that comes from,
 because if we're all at risk
 because of these few people doing something,
 they're not having the same experience as the large team.
 So maybe it's like small teams doing something
 on the side of a big team
 is where we get some of that innovation.
 I don't know.
 So I'm kind of curious about like,
 so a few programming ideas that a lot of people use,
 like that you regularly use in your programming came up,
 one being like discriminated unions or tag unions
 as sort of like forming this like mutually exclusive
 branching structure, as opposed to like the fat struct
 model where it's like a just it's one unified type i'm i'm kind of interested to hear like what
 you think about like um both of those things are you've said are like good in their respective
 situations i'm curious about like when you know that introducing boundaries of mutual exclusion
 like in a discriminated type is useful whereas the uh the the sort of uh large fat struct thing
 stops being useful in those cases so I don't really think of them as distinct I think of them
 as sort of the same things I'm just trying to use terms that other people think in to communicate
 that so the way that I normally think about it is there are two types of situations I might find
 myself in one is where the domain model itself like literally the thing is telling me clearly
 that these things are mutually exclusive and that might be a place where I you know have more in
 common with the oops side of things because I'm like,
 I see why you guys were thinking about
 if that was true about this thing.
 So in those cases, I would use a discriminated union
 because I prefer to write code in like a verb oriented way,
 not an object oriented way.
 But I'm just doing the flip side of what they're doing
 with their virtual function in those cases, right?
 I just think it works out better in my way,
 but that's just, you know, that's my personal opinion.
 It also has to do with what type of system you're making,
 whether or not people are gonna be adding types
 to the system more frequently
 or whether they're gonna be adding actions.
 I tend to find that people add actions more frequently.
 That's why I focus on that.
 But either way.
 That makes sense.
 So if I can see that this is by definition
 mutually exclusive, then I'm discriminated union.
 And the reason for that is the exact same reason
 for strewstrip and everybody else to catch errors.
 I don't wanna be using,
 I don't wanna make that a fatty struct
 where I'm accidentally doing code
 that's gonna do both things.
 So I try to basically replicate that Simula-style thing,
 or really it's Tony Hoare's, right,
 Sir Tony Hoare's idea of that.
 I try to replicate that and it's just unfortunately
 US Plus doesn't really have good support for that.
 Like I said, Santa Fe is not very good, in my opinion.
 The real thing that Tony Hoare wanted would have been great.
 So I would love that feature.
 The Fatty Struct, Qua Fatty Struct,
 and like I said, I mixed these two together,
 so I don't think it's that distinct to me,
 but the idea of feature flags or something like that,
 right, like I'm gonna hit this bit
 and then it means that this path might be taken,
 what the Plex guy, right, what Doug T. Ross
 would have called those switches, right?
 That, to me, is for mix-in, as they call it, right?
 When I know I'm combining lots of things together, right?
 Like a tasty stew that's going to be delicious, and it's going to taste fabulous when you
 use these entities, right?
 That's when I reach for that.
 And I think those are really, they're very simple.
 You can teach them to someone in an afternoon, and they can apply them pretty directly right
 away.
 And that's one of the reasons why I think they're so much better than things like the
 compile-time hierarchies, where, you know, I've seen programmers tie themselves in knots
 and spend months trying to do something
 that literally that approach,
 it would take them 30 minutes, right, so.
 And I'm a little confused about the,
 like exactly what, so Looking Glass,
 you introduced them as using like
 sort of the fast track model,
 but it sounded like they ended up with an entity
 like component system thing
 where they split everything out into,
 like they pulled out common parts of entities
 and put them, isolated their storage.
 Did they make that transition
 or did they use one early and then the second later?
 Can I ask a question to the audience?
 Yes.
 Sam, how much time we got?
 We still have time right now.
 Maybe, well, it depends.
 There are multiple paths that could be taken.
 And the split point is in about 25 minutes.
 How badly do you want a complete version
 of that answer versus a summary answer?
 Because I can answer that very accurately.
 Yeah, let's go with the accurate one.
 Okay.
 Deleted scenes to keep this talk somewhat under two hours,
 which hopefully we did and now won't do.
 So I'll skip some of this just to keep it relatively quick.
 So inside Ultima Underworld,
 an entity was basically a fatty struct overlay.
 So the way that it worked is you had an entity
 and then if there were two separate things
 like hit points and fuel
 that were generally mutually exclusive,
 meaning an entity probably can't have both of them
 because fuel is used only for like lanterns
 and lanterns don't have hit points,
 then we'd put them in the same place, right?
 That was Ultima Underworld, right?
 And of course this is rough because it's like,
 it means that when you're accessing one of these,
 you're secretly also accessing the other, right?
 they're in the same place and so you could have an error where you were doing something
 where like you're checking the fuel or you're checking the hit points in this case like you're
 checking the hit points but you're secretly checking the fuel and then you delete the entity
 you know because that's what it was thinking right and this is mock he didn't his picture didn't make
 it in i'm glad i get to show him now he's the guy who did a lot of the implementation on the dark
 object system he came on the scene in ultimate underworld 2 and he's the one who coined that
 phrase that quote i put up that's him the compile time hierarchy he's the one who crystallized that
 right he comes on because the uh in the earlier earlier ones like it was doug church and dan
 schmidt and a bunch of people who did ultimate underworld one he comes on of underworld two
 and he actually literally had the that bug that fuel bug he wrote a thing for damage where if
 you threw an empty lantern at a wall it would enter the damage system because it was supposed
 to take damage from hitting the wall and it would be like how many hit points does the lantern have
 it'd be like zero it's like well i guess it's out of here and so empty lanterns thrown at walls
 would just disappear right and so we had to fix that bug by doing exactly what you expect he'd
 have to like check you have to manually add that code and so you know they didn't like this because
 remember these guys and again much like you know ivan sutherland and doug ross these guys were
 super smart mit people and and sutherland's also carnegie mellon and caltech right it's like kind
 of nuts going through the whole gauntlet there uh the folks at looking glass are mit graduates
 they're super super smart guys they do all this amazing stuff so they don't want to they don't
 want to have this happen right they just don't know what else to do because they have these
 like really hardcore memory constraints and furthermore they talk a lot about the um the
 sort of uh trade-offs you have to make so if you have a fuel system that needs to store stuff and
 you have a combat system you store stuff and you do make space for them um it means that if you do
 you know if you're using that overlap it means that if you then decide you need an entity that
 has combat and fuel because we wanted to add that it's like crap i've got this overlap i can't do
 it so now i have to make a trade-off like maybe i shrink the amount of data that the combat system
 can store and that sucks right because now i'm forced into this this decision i didn't want to
 have to make and that's just you know what the kind of situation they're working on working
 under the kind of constraints they're working under when they go to do system shock which is
 the rpg so they do ultimate underworld one two and they do system shock i'm just following their
 lineage they also they have terra nova and flight unlimited which i won't cover because they're not
 the same uh in terms of like lineage really for the teams and how they were doing rpgs it's just
 It's just the RPGs from Looking Glass.
 So it kind of looks like that.
 I'll skip this because it's not part of the talk.
 They go to an outlinking kind of structure.
 So what they do is they say,
 all right, we kind of want something better than that,
 so what we're going to do is we'll have our entities,
 we have a little bit more memory to work with now,
 so we'll have the entities have their shared part up front
 that everyone roughly has, so it's kind of fatty,
 but not that fatty, and then everybody gets
 one pointer out to something, right?
 And we'll try to make those things be things
 that don't have to combine together,
 but it's still a limitation, right?
 they can't have two of them which they would have liked to have had so that's how they got there
 that's that's what system shock was it was like one outlink per entity that could extend it and
 now that solves their growing problem right it's like we can just grow things arbitrarily and they
 don't like overlap some unrelated system or something like that but it doesn't really allow
 them to combine them in that way that they would have liked so it's still almost the same
 limitation it's just more of a memory optimization at this point right um but it also catches this
 error because now you sort of have a discriminated union going on so you can't access fuel off the
 base entity because it doesn't have it so you have to do something like this where like if it's a
 light source i can get the light source or better yet i can only return a light source pointer if
 it was a light source and so that i it's kind of more foolproof that i can just check one pointer
 and good to go right again i'm blowing through these but yeah this was me making fun of standard
 variant yeah um so uh flight unlimited this was i'm just going into because it sets up the
 to the entity component system thing,
 Flight Unlimited actually had,
 it was the first thing to use C++
 really heavily in the company.
 And so they were using new and delete
 like you're supposed to do in C++.
 And unfortunately, that totally fragmented memory,
 totally like thrashed out memory and fragmented memory.
 So I don't know if this is well known,
 but basically, Flight Unlimited is a game
 where you like fly around, you know,
 in a thing and whatever.
 It was a very popular flight some of the time actually.
 And you'll notice that in the cockpit here,
 there's gauges, but there's no fuel gauge, right?
 There's no fuel gauge on there.
 It's just, it's other stuff.
 There's no fuel gauge at all.
 But sometimes it would say out of fuel,
 which would be like out of fuel, right?
 And what out of fuel was was actually
 the memory's too fragmented.
 So what it would do is it would say out of fuel,
 it would close, it had like an executable
 that was sort of running as sort of a batch restarter
 for the main executable.
 It would just close the whole rest of the executable,
 so it would still save the game state,
 close the executable, reload the game state,
 And you know, then you were, there you're back to good.
 This is Tom Leonard.
 So Thief the Dark Project comes on the heels of this.
 This is Tom Leonard.
 He's actually the guy who, as far as anyone can remember,
 that I've been able to, you know,
 that I've been able to get a solid story about.
 He's the guy who actually comes up with the idea
 of sort of the entity component model switch.
 And I didn't really call it, again,
 too much stuff getting cut that we're going into now,
 so you know, I guess six of one, half dozen of the other.
 But the idea of saying, okay,
 instead of entity.getHitPoints,
 we're gonna say HitPoints.getEntity.
 It's a big, like that's a big switch
 if you've never thought about it before, right?
 Here's the one that like mock says,
 I think it was Tom who came up with that.
 And the reason is so that the types line up.
 So like now, instead of having like either tons of functions
 like get a HitPoints-like thing, get a this,
 that are on, you know, an entity, which would suck,
 now we just ask the actual thing, the HitPoint system,
 and it's only gonna return one type,
 which is like a HitPoints type to us, right?
 And so, anyway, this is what they're thinking about when they make the entity component
 system.
 And it comes from all of those experiences that they've had.
 They want to avoid fragmentation because they just had to make a thing that, like, restarts
 the game, right?
 Which was Flight Unlimited.
 They want arbitrary sized properties, right?
 Because they don't want to make those tradeoffs between combat systems and fuel and whatever.
 They also had additional things, which is, like, they wanted designers to be able to
 create types at runtime.
 So they kind of want bags of properties that they can have designers create.
 They want designers to be able to do things like create domain model hierarchies in the
 editor because they're thinking in terms of the domain model and it's just not implemented
 that way, right?
 So they do those things.
 And then finally, the how fast is the fastest case thing.
 That was from Doug Church.
 He was like, okay, if we're doing all this pie in the sky stuff, we have to figure out
 some way that it's still going to be as fast for like physics to compute and stuff as what
 we used to do.
 And so what he did there was he was basically forcing them to go, we have to consider some
 way that this is all going to work.
 was the system boundary drawings part so that's the really fast part of this and
 by the way this is what it looks like inside the dark object system if you
 want to create a property type right it's like I said it's still looking
 right like like you could pass this by an OOP person and they would be fine
 with it I think so it's like again not not OOP it's just not that hierarchy
 thing right yeah so so there you go I think that's everything
 All right. Let's see what else I've got.
 Yeah, so I guess one interesting thing about what you were saying
 is that what it has to do with, like, the object-oriented,
 the original object-oriented work came from these, like,
 distributed systems and everything.
 And I know you've talked a lot about in the past, like, Conway's Law
 and how, like, introducing these boundaries,
 or not introducing these boundaries,
 it's the fact that when these boundaries arise they cause friction or difficulty and i guess um
 would you characterize this object-oriented thing as like creating those boundaries unnecessarily
 so they didn't arise from the problem and so they're causing they're causing difficulty in
 that way um i would sort of say that i guess the only the only like caveat i can think of there is
 i think that the part where you said the problem arrived like the problem doesn't arise from it
 or whatever or the you know it doesn't arise from the problem i think that's how you phrase it
 i think a person who thinks in terms of object-oriented programming and is an aficionado
 of that would claim that it is arising from the problem because the domain model looks like this
 right and so i don't agree with that but i don't know what they would agree with right and so from
 my perspective i agree with you these are things that just because as a human you're going i like
 to categorize things into groupings because that's something that we do right linguistically
 it's all quantum physics at the end or something right bro so it's like these are arbitrary
 categories that we're drawing there's no reason to think you know just like i don't think the laws of
 the universe think of you as ryan flurry in a computational sense but i think of you that way
 it might not make sense for you to have the computational version of ryan flurry
 be about ryan flurry instead of just a collection of things that produces to the end user the effect
 of ryan flirt right so to me anyway that's sort of the difference there right it's like i don't
 see that the model inside the computer may have very little to do with the model experienced by
 the user which again is in direct conflict with like what alan k wanted to do he wants and again
 you have to remember the mindset he also comes he wants to do education he wants to teach people
 about computing he wants it to he wants it to feel like you're programming in the same way that you
 see the real world and in some ways i think if we could just get to the point where and maybe he
 does think about this now i'm not sure just at the point where he says thinks oh well that's just
 that's just when you use an application that's what it feels like it's not what it is under the
 hood then i think i'd be right there with him right so yeah interesting um all right i'll
 I'll check my list, and then maybe if anyone in the audience has questions,
 then I will ask.
 But I'll check my list first since I'm up here talking about it.
 Okay.
 I had two pages.
 I did that one.
 Oh, yeah, I guess another thing.
 So I guess some of these are, like, not exactly questions,
 but they're, like, I formed a mental model given your talk,
 and I want to run it by you and see if it makes sense.
 So one of the things, another thing that I guess is implied
 by introducing these boundaries between parts of your program
 when you could have not done that in the architecture,
 but you did for one reason or another.
 The interesting thing is that you were talking about a sketch,
 is it Sketchpad?
 Yeah, Sketchpad.
 You have some layer which is like, quote unquote, omniscient.
 like it knows it it has full context of what's actually happening and in my mental model i'm
 like that's similar to when like an actual like civil engineer or something is like going and
 building a bridge like they they're not like how do i build a bridge without knowing what
 the landscape looks like kind of thing so it's like um in that in that so a lot of the design
 decisions in c++ or in in all of the other paths that you that you iterated it seems like they're
 about like removing context or trying to find the minimal set of context but i assume like that
 doesn't seem how i haven't found that to be helpful because of you what you have taught
 basically but but i'm i'm curious i kind of feel like you're on your own orbit now and you totally
 know exactly what it is right i mean like yeah honestly you're one of the best system architects
 i've ever seen full disclosure right well folks at home seriously like it's insane so you don't need
 me all right well thanks i i appreciate that but um uh so i guess uh you know i think that's
 probably it i'm having to turn through these two pages here uh but well to answer that question
 though like about the like removing that context right i do think like that's part of why it's
 frustrating to maybe look at the history a little bit yeah because what it looks like to me
 from like the the bird's eye view is like instead of asking how do we achieve code reuse
 and modularity while preserving our ability to solve the hardest problems it looked more like
 it was like let's just redefine the problem to be simpler and solve that yeah and to me that that
 was one of the big things about the sketchpad thing as well where it's like okay you had working
 examples of this that are pretty well documented i mean if i can go figure out most of it now
 looking back than at the time when you could have actually talked to Ivan Sutherland fresh off of
 the implementation when you remembered it all, right? And so it does really feel like, I feel
 like there's a failure to engage with the hardest problems. And I think one of my takeaways from it,
 which, you know, from reading the history, which is not, it didn't really change my mind about this,
 it just reinforced kind of like my feeling about it, which is, I think when you're designing new
 things, you should focus on the hardest stuff. You should say, what solves the hardest problems?
 because we can always then take that and scale it down and remove things from it or dumb it down
 for an e for people to use in cases where that aren't as hard but it's almost impossible to
 take something that only solves simple problems and scale it up into something that solves hard
 ones and so that was that's really the thing and i don't i don't blame anyone in this uh that i
 covered here for that at all because the conditions they were working under are awful right i mean they
 have no they have none of the benefits we have today they were working with
 computer systems they barely got time on half the time it was hard to debug
 print all that stuff and they're having to invent all this stuff themselves
 right they have nothing to fall back on so it's nobody's fault but going forward
 it's like when we have good tools let's attack the hardest problems and that
 will be where we get our really good architectures that's my feeling about it
 anyway do you blame Y Combinator at all for like the Internet I'm about to
 blame them when I see what they post about this talk and somehow managed to
 to miss all of the good arguments you might have about it
 and argue about something else,
 like whether or not that was the right use
 of discriminated union, which 100% will happen, right?
 And you're just like, guys, who cares?
 Like that does not matter right now, right, but okay.
 Yeah, because I think like actually programming,
 that tends to be one of the harder problems is no,
 like, well, I don't know.
 You've said it a hundred times already in the talk,
 but where you draw those boundaries,
 because it's not that modularity stops being useful,
 it's that it's a wall you're introducing
 that makes something more difficult.
 And so if you put that right into the middle
 of the hard problem, like you say, yeah.
 And I think that is the fundamental struggle.
 It's why architecture is so hard.
 And it's also why architecture
 is potentially difficult to reuse.
 Architecture, not like reuse inside an architecture.
 And it's because when you draw
 those encapsulation boundaries properly
 for a particular problem,
 you save orders of magnitude of work
 when you do it properly.
 And the way you draw them could very well be different
 for different types of things you're trying to solve.
 And that makes it hard to say,
 okay, here's an architecture that just works across things.
 Or one of the reasons the compile-time hierarchy thing
 I think is a bad idea is not just because
 I don't think it's very useful in general,
 but it's also because it's Procrustean.
 It's like this one-size-fits-all approach
 that I don't think really even fits that many problems,
 but it certainly doesn't fit all problems, right?
 And so teaching architecture,
 I think it would be better to focus
 on more flexible thinking
 and thinking about drawing the encapsulation boundaries
 with intent, not with a fixed model in mind.
 And if that intent leads you to a very unusual placement
 of the boundaries, as long as you can prove
 that it's actually getting you that leverage
 and not introducing cuts in places
 where it makes programming difficult,
 that then you should do that.
 You should follow that sort of weird structure
 because that is probably right.
 Yeah, that makes sense.
 Okay, well, I think I've exhausted all the questions
 discussion topics um or they would be rehashing things that you like i wrote them down and then
 you covered them in the talk and i was like okay um so i'll ask the audience does anyone
 have should we also should we just cut now is that good time to stop because
 okay okay shoot sorry sorry everyone um okay uh uh rafael do you ever do you have a question
 you could just speak out yes like um if we had the solution in the 60s and we saw the power of
 of Sketchpad, and why was, let's call it Dark Oop,
 still able to gain foothold and catch on,
 suppress the good solution?
 Was it because, was it a successional knowledge transfer
 problem, or was it just because Dark Oop is such a
 catnip for programmers, which is a lot of interesting
 problem, how would it represent that,
 or was it something else?
 Why did it catch on?
 I mean, it's very speculative to try and guess
 something like that, obviously.
 I think you touched on some of the answer there,
 which is that I do think people want to divide things
 into hierarchical categories kind of naturally.
 I mean, we did that with the natural world
 when we were trying to do biological classifications
 long before we had really any basis to do so,
 like before we knew about DNA or anything like that
 or how those things might have happened.
 So I think it's a natural thing for people
 who want to do to make those classifications,
 so there's some of that.
 And thinking that there's this easy sort of model
 that just goes from what you see,
 it's like WYSIWYG architecture,
 like what I see in the real world
 is just what the code looks like and we're done, right?
 So I think there's a little bit of that,
 but I think the real story is just that history
 is very messy and in order for something to gain traction,
 somebody has to champion it,
 someone has to do the work of implementing it
 into a system and doing a good job of that, right?
 One of the reasons we got
 the sort of compile-time hierarchy thing
 is because that's what Strewstrip kind of took away
 from Simulets, what he implemented first
 into a language that became very popular.
 And he wasn't trying to do anything nefarious, right?
 He wasn't trying to do anything dark.
 He's just like, I like this type checking thing.
 I used Simul, it was kind of cool.
 He did the work, right?
 I mean, you could say that about things
 that we see happening today as well.
 It's like, you know, in order for something like, you know,
 Rust or something to gain popularity,
 somebody has to build Rust first.
 Somebody has to have an idea of what it's going to be.
 Is that idea good or bad?
 Who knows, but in order for it to even get judged
 in the marketplace, someone has to do that.
 And the bottom line is nobody who looked at Sketchpad
 was thinking in terms of architecture
 other than what I said,
 which is like the virtual dispatch basically.
 And you know, I didn't go into the talk,
 but Alan Kay was, he was predisposed also
 to think about that virtual dispatch
 as being very important
 because the other references that I didn't mention,
 but they were in that quote,
 I said we're not gonna cover them.
 They're like the Burroughs 5000 series computers
 and there's this Air Force,
 this guy who wrote a file system thing
 where you put the way that you use the files
 in the file system were subroutines
 that were stored in front of the files in the file system,
 so it was kind of like a virtual dispatch thing.
 The Burroughs 5000 system also had
 this kind of virtual dispatch,
 where there were tables and things,
 and so for Alan Kay, who we didn't really cover in here,
 the other three hours of slides, they're all there, right?
 But what he actually was seeing was
 he was seeing commonality there.
 He was like, oh, the Burroughs 5000
 that Air Force thing that I thought was cool,
 Simula and Sketchpad are all doing this dispatch table thing
 and they're all like making classes
 with these dispatches on them.
 And then he's thinking about your biology
 and this messaging, like you're gonna respond
 to these messages, that's what these dispatches are,
 they're like how you're responding to different messages.
 And he just goes down that path
 because he's thinking that that's the core thing, right?
 Because he's predisposed to see it
 because he's encountered this idea multiple times
 and so he's predisposed, I think,
 I think that that's where the power of Sketchpad comes from.
 Because, like let's face it,
 would we have recognized that power at all
 if we hadn't had all of this experience
 and like, you know, I just randomly kind of
 stumbled upon this like, oh wow, wait, okay.
 Like that's really kind of interesting.
 If I had never seen an ND component system before,
 would I ever even have thought of that?
 Probably not.
 So I think it's just, it's really hard,
 it's a really big ask.
 It's a tremendous ask to ask someone who's like
 inventing C++ or inventing Simula
 to somehow get all of that.
 It's just not, it's just not plausible.
 You know, it's not plausible.
 It's a hindsight thing, I think.
 We have a question right here.
 So, it seems to me that the pattern is always the same.
 Like, you kind of come from school,
 it was my pattern too, and it seems that it's yours, right?
 You learned a certain way, and in school,
 everything's kind of tied to business stuff, right?
 So it's very easy to think about,
 you have a client with an invoice with items, right?
 And usually, it's not even,
 It doesn't go that deep into very high hierarchies,
 but we kind of just learn that pattern,
 and then we just start using it,
 and you have a hammer that is a melee weapon
 that is a weapon and whatever.
 And then we have to have the luck
 of finding somebody along on our path
 that kind of snaps us out of this
 and shows us a different path.
 But also, these people are kind of disappearing
 from the industry.
 So my question is like, how do we fix this problem?
 How can we improve this?
 Because it kind of feels like
 You're trying to get smokers from stock smoking long after they're smoking, you know what I mean?
 Well, I guess I would say you're at the right conference.
 I mean, that's all I...
 I mean, I don't know.
 You start doing stuff like this and you try to go through the history and show how it happened and stuff like that.
 And that's it.
 The best you can do is put these ideas out there, suffer the hacker news thread that you will then have to endure or whatever else has to happen.
 and then you hope that maybe some of those ideas get picked up
 and people think about it more critically.
 I think we're out of time, correct?
 Yeah.
 There is coffee.
 We're going on break now.
 We'll be back at 20 past for Dennis.
 All right.
 Well, I hope all will be in the audience anxiously watching this talk.
 This is from Teardown, right?
 I think so.
 Okay.
 I'm excited to see this one.
 I'm really looking forward to it, Dennis.
 All right.
 So we'll be back here at 20.
 Thank you, Ryan.
 Yep.
 Thank you.