Casey Muratori – The Big OOPs: Anatomy of a Thirty-five-year Mistake – BSC 2025

Please join me in welcoming the one, the only, the irreplaceable Casey Muradori.

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.

Uh it's been a very long time since I've been really excited to give a talk and uh a lot of that is because the the the speaker list of this talk is is of this conference is absolutely amazing and I just I don't know I'm I'm really excited

to be here and I'm excited to give this talk. So I'm just going to jump right

talk. So I'm just going to jump right into it. So, I would like to talk about

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 incredibly influential game company that did a lot of uh firsts in gaming. Uh, one of their games, Ultimate Underworld, started kind of the 3D revolution in, you know, PC

gaming. And they they were incredibly

gaming. And they they were incredibly like 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 they might not know who they were, but they were incredibly important. And one of their games uh was

important. And one of their games uh was called Thief: The Dark Project. And it's

a franchise that lived on. It was one of the first sort of stealth action games.

And it looks pretty primitive by today's standards, obviously, but this was a 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

anyway. I'm not a graphics guy. What I

want to talk about instead is how they modeled entities. And normally the way

modeled entities. And normally the way you would do things in games at this time and in fact the way that Ultimate Underworld 1 and two and then later System Shock was another one of their games. The way that they did things was

games. The way that they did things was actually the way that like uh me and for example Ryan Flurry who's going to be interviewing you after we would say that this is a good way to do things even today. They were sort of fatrus if you

today. They were sort of fatrus if you will. They just put everything in one

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 you know these were very very

it. But you know these were very very limited resource times. I think the systems uh you know you would expect to have something like 2 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

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 is nothing to do with how

world. This is 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 Looking Glass had ever really used in that lineage of games in their RPGs. And they decided not to go

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 uh you would have seen pushed if you were reading like architecture things in oops law or you know 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

things. The same things that were in our fatty strus when we do a more serious architecture here doing more architectural work. We want to put

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 strct. 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 or I'm just imagining systems you might have in a game. And in so doing, in 1998 when they shipped Thief the 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

component system. That's what we call it today, right? People call it this. Uh

today, right? People call it this. Uh

this is now in an invogue architecture in much the way that those hierarchy kinds of architectures were in vogue at the time and still to some extent are in today, but not necessarily in the game industry. So, this is the first time I'm

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

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's a a pretty interesting

time. And there's a a pretty interesting thing that you have to understand about this. And I know this may seem like

this. And I know this may seem like beating a bit of 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

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

the objects. So the encapsulation boundary in a normal oop like hierarchy is I have whatever 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

knows about. But that's very different than this. This is about all of the

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

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

programming. It still obeys a lot of the principles you might recognize from object. It's not like they were saying

object. It's not like they were saying we're getting rid of object-oriented programming. They were saying something

programming. They were saying something very different. And they were saying

very different. And they were saying effectively what Mark Blank said, he's the person who actually uh 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 going to think about, you know, birds and are they, you know, is it a mammal or is it an aven thing, right? You're thinking about this domain

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 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 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

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

write. It's are those boundaries in the right place. So this is crucial and this

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 uh you may have seen it. It's called the internet. It's like

it. It's called the internet. It's like

this series of tubes that connects people around the world. And it's 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 could be 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

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 uh some people talking you 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 you know we have old old things that were like maybe not quite architecture like those fatty strus 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

like much you know cleaner it's much better organized it's better architecture and they started to push this right and it definitely got adopted got adopted everywhere and it's a very standard paradigm even to this day and

they were they were sort of responding to people who are saying this is bad that this hierarchical thing is not a good idea the capsulation 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 like academic studies

and ways of looking at things and we've we definitely have great examples of 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 it 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%

what we're saying. And the long answer to this is the rest of this talk.

Welcome to the Better Software Conference, the inaugural Better Software Conference. This is the big

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 bought in, right?

Low-level programming, that sort of thing. You're probably like, "Okay, I

thing. You're probably like, "Okay, I like where this is going." People on the internet, as I said before, you know, maybe that was a mistake, but they're going to have some some uh some issues with some bones to pick. So, I just want

to say first, when I say the big oops anatomy of a 35-y year mistake, I'm not talking about uh OOP as a whole. I'm

talking about looking for very specific things in it. Okay? And because whenever you talk about oop, it's always this thing where people feel like, well, whatever you're talking about, like that's not really OOP. Like you're

you're talking about the 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 OP is or something. And and I don't

or something. And and I don't necessarily blame them because it's a nebulous term and they have their own definition for I mean I probably have my own definition for that's totally fair, right? But I just want to say we're not

right? But I just want to say we're not going to be dealing with any of that here. So, I don't want to hear the the

here. So, I don't want to hear the the whole like, you know, I don't know. It's

sort of like like wine, which I got the slide up in here. It's like you if you have like a designated origin, you you're not allowed to call it certain things. And it's like it's that kind of

things. And it's like it's that kind of feel, right? It's not like it's like

feel, right? It's not like it's 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 it was a

specific. And I'm not saying it was a mistake. I'm saying this was a mistake.

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 threat. 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

historical record. It is so obvious that everyone actually 100% meant you should look at the domain model and you should code that directly into compile hierarchy. For example, here is

hierarchy. For example, here is literally Bjarn Strus'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. It's like this is

introductory book. It's like 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, you know, kind k is an enumerate there of like what the kinds of shapes are, right? If we're going to write something

right? If we're going to write something like this, we end up with code that has a switch statement in it. So we want to draw something, we have to say, oh, what what is this? And I have to say, okay, case circle, case triangle, and have the different drawings for that. And he's

like, this is a mess. You you can 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 deres from it the triangle class and 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 objective programming, literally what we're talking about is inheritance hierarchies with virtual function calls.

like he says that and he says object 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 K because he was a big father of a compar he's the one who coined the term as far as anyone knows

uh and he talks about you know uh this this sort of idea that oop only means like messaging and a few other things right he's said this and so some people might be like well That's what object programming was really about. No one was

ever pushing it. And and you know, Jerus, okay, whatever. C++ is terrible.

Like he that don't listen to that guy, right? Despite the fact that he made the

right? Despite the fact that he made the language that's like 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 this is the truth.

years. And so this 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 did he say it? It's because 10 years earlier, he was already saying he kind of 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 uh you know, it's

it, right? It was just uh you know, it's really good, but no one can figure out how to use it, I guess. Uh so that's a little bit weird. I don't know. Maybe

Alan K, 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,

exactly. But if you go back earlier, because small talk is a lot earlier that if you go back look at what they were actually talking about when they were talking about small talk in the times before they had 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 like, I'm going to start with completely undifferiated 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 like cool things, computer architecture. He's like, we can

computer architecture. He's like, we can have a generic object and then we can drive from that a rectangle and we'll drive a window and a painted window and a browser. Look, everyone is talking

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 small talk. We have

all the data like for this all of the papers exist. Here is an example from

papers exist. Here is an example from the art and science of small talk where they're talking about some stuff that's needed to adapt values like I want to convert values between things and you know 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 cuz, you know, like 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

shape example. You know, you're just cherry-picking. Except it exists

cherry-picking. Except it exists absolutely everywhere. It's in small

absolutely everywhere. It's in small talk. There it is. They have a path

talk. There it is. They have a path class and from that path class they have different shapes derived from it. That's

what this the path looks like. That's in

the base language of small talk that Allen K and uh Robson shipped and Adele Goldberg was the person who documented it. These are the original authors of

it. These are the original authors of small talk. Right? And if you don't want

small talk. Right? And if you don't want to take my word for all of that, you can take Bjarn's word for it. He criticizes

small talk for being all about inheritance. that that's all it was and

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 that's why I'm still able to use C++ to this day is because Bjan Stra was actually really smart about a lot of things and he didn't try to force you to do things only his way where Small Thought kind of did.

All right. So, now that we've got that out of the the way, let's talk about the origin story for this guy right here who has caused me so much pain. And you

know, I won't go into it. Anyway, let's

talk about the origin story. So we'll

start uh 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 not

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 it's not

even just C++ it's like the knock-on effects of C++ also. So this is really really important uh as an entry into where this came from. Let's start in 1978 and looking at that and uh Bjnusup

is actually in the uh he's in university at this point. He he hasn't actually gotten to Bell Laboratories where he would do uh 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 languages guy he's not there like 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 uh 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 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's like no there's no way he was going to 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 to to write the simulator because earlier in his career he had well he'd been in university I guess early his education I

should say he had been at university and he learned uh from a person named Kristen Nygard who was actually one of the creators of simula he learned the language simula directly from one of its authors basically like he he was

actually there at the time uh when the author was also there and this 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. 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

that." So, he ended up with this thing where he had like little programs that were simulating what was happening in a distributed network uh or distributed system, I should say, not necessarily on a network. And he found that it was

a network. And he found that it was really easy to debug the little programs by themselves. And the language made it

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. Uh it was it was a lot of reading,

lot. Uh it was it was a lot of reading, right? So I'm trying to convey it to you

right? So I'm trying to convey it to you in in case possible 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 the domain right? He said

that was working really well when he was implementing. He was just saying, "Oh,

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

directly." And that was working really well for him in Simula. And you know, we can kind of start to see how this is breaking down. He happens to be working

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. Okay, so we used hierarchies for this, right? 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

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 had 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 like TypeScript, right? Most things that we work with

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 like 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, Struestrip 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

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 typeecking on classes is really good, right? And

you know just to split those down the middle, I do think the type-checking part is pretty good. 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

right? But at least half of it I'm with him on already even. Okay, 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 uh what happened was Bjnestrip was doing stuff with distributed systems and he wrote this thing in simula and it was a great time and so he decided to do when he got to Bell Labs was make C++ and it it would

just have you know the classes in it from Simula. It was great. No. So what

from Simula. It was great. No. So what

actually happened was the entire thing completely rolled over and died. He tried to run the simul

and died. He tried to run the simul program and he had all sorts of problems with it and it started even before he tried to run the simulate 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 I mean, I almost want you to read it.

If you compiled 130th of the program and tried to link it, it was slower than just recompiling the entire thing. Okay,

let that sink in because it means that that Bja was talking about Unity builds in 1994. He was like, "We can speed this

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. Anyone want to guess why it's slow? It's a rhetorical question. I'm

slow? It's a rhetorical question. I'm

going to tell you why it's slow. It was

so because the garbage collector, same reason things are slow today half the time. The garbage collector was taking

time. The garbage collector was taking any 80% of the runtime apparently even though there was no actual garbage that needed to be collected because you know I guess at that time garbage collection was even you know very very primitive obviously so it's probably running all

the time just to see if there was any garbage and it was like yeah nope no garbage and that was happening a lot so 80% of the time so he had he had the experience with simula

that we have with C++ like it is the chain continues right uh 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.

happened. So it's kind of interesting.

It precages everything, right? It kind

of the whole thing is almost like a microcosm. So if we reflect on this for

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 like, you know, here's the thing that you just don't understand. It's all about large teams.

understand. It's all about large teams. You know, it's all about these large teams. It's just that you 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?

encapsulation. It's amazing, right?

How big was the team that Bjestro 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 a like analysis of what we're going to do with lots of people. So you could argue maybe they turn out to be good for that. But you certainly can't argue they

that. But you certainly can't argue they was designing it for that because they weren't. They were doing it for

weren't. They were doing it for themselves. Strus was doing it for the

themselves. Strus was doing it for the the protection, the type protection, the error checking, that sort of thing. He

wasn't doing it to and also like the virtual function kind of stuff. He

wasn't doing it uh for large teams because everyone at Cambridge University was helping out in the product. No, he

he was a lone wolf coder. He really was.

So anyway, goes to Bell Labs. He makes C uh with classes, which is the first thing that uh it's the original name of C++ called C with class because that's what's going to be. It's going to be taking simul type system and putting

something like that into uh into C. And

the reason for that is pretty obvious.

He goes to Bell Labs and C would be like a lingua frana there probably, right?

Because they're the people who make Unix. They're the people who make C like

Unix. They're the people who make C like the people uh 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. Uh he's he's trying to do those things for Unix. He wants to analyze certain behaviors of it and that

sort of thing. And he finds like 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

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. Like he

talks about the fact that he says like all program parts can poke into all of the memory. And like C++ doesn't really

the memory. And like C++ doesn't really change that, but I think he's just kind of talking about like, you know, private declarations, right? He's just like,

declarations, right? He's just like, well, you know, I I 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 like I don't really want to make those mistakes where I access the private part of things, you

know, I want to be able to wall those off. And he's thinking about actual

off. And he's thinking about actual hardware, computer hardware. That's

where that idea comes from. Again, it

doesn't even 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

feature. Just like the computer stops it, right, 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, right? Are they

readon or are they writable? That's what

const is to him. That's where he thinks 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. Uh and by the way, these

documents. Uh and by the way, these aren't hard to find. Like these these just come from the D& which is a very popular book that he wrote. Uh that's

just collection of his papers, right? So

a lot of this a lot of the stuff in the first part of the talk you don't have to dig that hard for. All right. So anyway,

we get sort of a second wrinkle at this point. And what happens when he starts

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

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 you know 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

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 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 simul 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 produce even if it really doesn't have much to do with anything. That's sort of an

adjunct split. I just want to include it

adjunct split. 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 what he was uh one

languages. So that's what he was uh one of the things he was doing with it in addition to the domain modeling part which is more of a direct mapping. Okay.

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. Uh as

soon as he got like 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 okay 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.

Okay. So that's kind of the end of it and virtual functions come in a little bit later. The first version of C with

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

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 to be make it simple and efficient. So he was thinking primarily

efficient. So he was thinking primarily about I I want something kind of like what Simula has for this ability to call functions without knowing the type on them. uh but I want to make sure it's

them. uh 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 uh directly with Simula. So again, reflecting on

with Simula. So again, reflecting on this, it's totally different from what you would think if you just read like the capsule summary. Like 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, you know, at a compile time and using it directly model the actual domain that I'm working in which happens to be distributed computer uh

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 that's you kind of got the

C++. I mean that's you kind of got the picture now. Everything else is like

picture now. Everything else is like after the fact. Everything else is post talk. Anything else about C++ was people

talk. 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, well, okay, if all this stuff came from Simula and him using Simula, well, where did it come from in Simula? like did they just make it up? And Simulator originally comes

it up? And Simulator originally comes from something called the Norwegian Computing Center. I mean we we are here

Computing Center. I mean we we are here very close to Norway I suppose. So some

of you may have known this place. I

didn't really know anything about it until I read that like you know was reading up on Simula and like okay there's this place. It's a quasi kind of private public uh institute for doing

computing research and it's it's in Oslo, Norway. And in 1962,

Oslo, Norway. And in 1962, these saucy gentlemen right here, uh, and I'm I'm apologizing like Sweden is the worst place to give this talk because now I have to pronounce their

names in front of people who probably know, uh, Norwegian pronunciation very well. And so I'm going to butcher it and

well. And so I'm going to butcher it and I apologize. It's Oly Johan Dal. Maybe I

I apologize. It's Oly Johan Dal. Maybe I

can pronounce that correctly. And

Kristen Nygard. And you already know Kristen Nigard's name because this is the person who Bjanna Trustup learned uh the simula from originally. He was you know he interacted with him a lot when

he was uh at his previous university before Cambridge. So these are the folks

before Cambridge. So these are the folks who make simul kind of like the masterminds behind it.

And the first reference we have to it is in private correspondence that has now been published uh from Nygard to a another person who was working on operations research. And these folks

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 to in order to optimize them basically. So you can think about things like we're you know

we're trying to plan how you know 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 car. I don't know anything like that. A

car. I don't know anything like that. 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 uh things things like the simplex algorithm if you ever heard of that that's operations research etc etc 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. Uh, this is in 1963. The

simul language would have looked like this. It's one of the earliest snippets

this. It's one of the earliest snippets I could find. And so this is not the way the final simul 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 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 we're

stations. It's like things we're 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 okay this is where the bottlenecks were or things like that you know and that was very successful. They

eventually released a thing called stimula 1 which was the first sort of more widespread version of this thing.

It was people loved this. They could do their system analysis this way. But uh

Nygard and D were thinking in their head like we really like this thing and we think it has more it has possibility to be bigger than what it is. Powerful just

what we had in that first version. So

they start to make a new version which eventually goes on to be called Simul 67. And this is like it's like Windows

67. And this is like it's like Windows 95 right 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

the language. So we have things like Alol having that or Cobalt 60 is the version of Cobalt that was first introduced in 1960, right? And so that's what Simul 67 would eventually be. And

they're trying to figure out what they're going to do uh for this new version. And what happens is they're

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. like 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 like a bridge with a toll booth on it and we've got cars going across it?" And they might be either trucks or

it?" And they might be either trucks or buses. What could we do so that we could

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 like duplicate all the stuff we said for trucks and buses?

That's what they're thinking of. And

this is not me saying this was this is them saying this is what they were think 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

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 superass that they're deriving from and they're going to have a car. Then they're going to say

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. Okay. So

in this one snippet we can see both things that not only they are about to do but that bjarnstrip is about to do as well. We are using this for reuse. We

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

model. But then mostly what we're doing is following the domain model with our classes. it is car and underneath it is

classes. it is car and underneath 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 is 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, right?

They're kind of talking about just this reuse part. That's mostly what they're

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, hm, we want to have ways that the

subasses can do things in addition to what the parents doing. And that's where the idea from virtual functions comes from. They say we have these operations

from. They say we have these operations that we were defining, you know, things like what that queuing behavior was going to be that I showed on the original slide from, you know, Simula back in 1963. And they're like, we want

to have those operations be modified based on whether this, you know, 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

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 had the sort of class hierarchies. I can see in the middle there, class sim set and sim

set class simulation. That's basically

saying like look, all of this stuff is going to be derived from like linked list holder. That's what simis would be

list holder. That's what simis would be like. Like I'm a person who holds link

like. Like I'm a person who holds link lists and then we're going to derive the simulation from the thing that holds link lists. That way it can use that. So

link 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

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. Right? That's not what's

hierarchies. Right? That's not what's happening.

So this is where we actually got compile time hierarch that matched the domain model because simula actually did have encapsulation. You couldn't refer to

encapsulation. You couldn't refer to things outside of the entities like that very much. And so it kind of did have

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 that's sort of

very good. Like that's that's sort of what happened. And it's not their fault

what happened. And it's not their fault cuz I mean they're in the wilderness, right? Like nobody knows any of this

right? Like nobody knows any of this stuff. We take for granted all the

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

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 they just wanted a link list. they just

wanted a way to say I have 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 want to do sort of the capsule version, that's, you know, again, sort of the this 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

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? Cuz

I want to know about following it the whole way back, right? So, that's the end. If you just use a capsule Wikipedia

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 but someone mentions, you're like, "Wait, what?" And then you go try to

"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 uh Nygard and Dah. They credit it to somebody

and Dah. They credit it to somebody else. C actually the guy who

else. C 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 claimed to invented a version of it that was

derived, pun intended, from work, right?

And this is the paper that they're referring to. This is the paper that I

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 uh sort

circulated. And there's actually uh sort of a further comments one happens after this. But they would probably be aware

this. But they would probably be aware of all of this because academics are always very good, right, at sharing their information this way, putting out publications. I mean, it's it's their

publications. I mean, it's it's their it's the thing that is cred for them, right? Like your papers are your cred.

right? Like your papers are your cred.

So you're reading papers by other people. You're writing your papers. So

people. You're writing your papers. So

they were uh they read this paper for sure. Which version exactly? I I

sure. Which version exactly? I I

couldn't tell you. But this is the paper. And here's what is talking

paper. And here's what 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, right? 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 subasses. And so he gives the

the subasses. And so he gives the example of an algebraic expression. He's

like, if you look at an 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, diatic expressions, right? He's trying to model

expressions, right? He's trying to model language. And by the way, this happens a

language. And by the way, this happens a lot. uh I don't really cover it much in

lot. uh 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 sort of thinking about how do we parse language how do we parse computer languages how we parse

human languages are 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 right and he's saying what about these subasses and he would literally write it just like this

so as we can see nyard and doll 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

syntax. You can see that he's saying I'm going to have an expression. Here are

the subasses of the expression. It's

going to be constant and variable, right? And so this is what NAL read. And

right? And so this is what NAL read. And

they were like, oh wait a second, what if we just had like our cars and trucks and buses under them and we could just use the car and then we put the car across the bridge. Okay, that would

work. Wait, but we don't have to stop at

work. Wait, but we don't have to stop at the car. We could make something above

the car. We could make something above the car that's like things that are in a list of stuff and then we could use it for everything. Doesn't even have to be

for everything. Doesn't even have to be the bridge. Holy cow, dude. Like, thank

the bridge. Holy cow, dude. Like, thank

you. Thank you, Tony. Uh, so anyway, yeah, Anthony. They call him Tony

yeah, Anthony. They call him Tony because I was 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, you know, I don't know, months at this point. Anyway, so

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

interesting. And we're starting to get into stuff now where like I had never heard before. A lot of this stuff when I

heard before. A lot of this stuff when I diged into it, I was like, how come everyone doesn't know this because it's super cool. When he presented this

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. There's FP people out there in the

them. There's FP people out there in the audience are 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 subasses inside it.

And you don't know which one you have until you look at the type. And then you can, you know, use whichever part makes sense for that type. And this is a super powerful programming. I use it all the

powerful programming. I use it all the time. And I think it's one of the best

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, right? A long long time ago.

right? 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 you know wouldn't been called a switch statement at that time but it's basically a switch statement that says I want to use this object and I'm going to tell you what each type you know which whatever the subtypes might be. I'm

going to give you a different block of code to run depending on which one they were. Right? Again, functional

were. Right? Again, functional

programming, I believe, would really like something like this, right? 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

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. uh sort

of you know 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 similar read the paper and that's how they created simula was or

the class concept in simula and the idea of subclass simula and then you know 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 nyard doll 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 Strrip

went to do his classes, he took it out.

He thought that discriminated us were bad because they broke modularity, right? It's because now someone from the

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? This is it's this paper by you know Anthony a s he's sir now by the way he he he he's he's been kned I

believe right um and again not a single part of it there's no no hint at all that any of this is really about compile time hierarchy stuff or about large

teams or about any of the things we talked 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

on it. How about that? Right? And that's

what I would have wanted. So, we had that already back when this paper circulated uh 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

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

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. Uh,

we've gotten back to kind of kind of the point of the first part of the talk.

There'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

stretch out. So, I don't know. Can we

take a break? Where 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, stretch.

Let's go to 25.

Okay. I'll see everyone back here whenever that is at 25.

[Applause] Okay, so as you saw in the first part, you come to the end a lot of times, but

then it's like, well, you know, is it really the end? If you keep digging, turns out you didn't really get to the actual meat of, you know, the the origin story. You didn't really get to the part

story. You didn't really get to the part where I don't know, I'm bad with comic books, but like, you know, Bruce Wayne and the Falling Pearls and the Joker and that kind of stuff. We 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 going to do here in the second half, I promise there's only this only it's one more half. There's two

halves. I'm not going to psych out again.

We're going to do here is we're we're going looking for Batman, right? So, we

left off. We've got this paper on record handling by Uh, right. famous for

quicksart like I said one of the 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 the most research that I could do in the time that I uh to figure out where these things came from. But I'm sure I missed something

from. But I'm sure I missed something somewhere. So if you're going to

somewhere. So if you're going to 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 alming language that was very popular at the time. It was in use since the the early

time. It was in use since the the early 60s, actually. Actually, it might have

60s, actually. Actually, it might have even been before that. I don't remember cuz it's not that relevant to to this particular timeline. But what they were

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 Alol up to this new version that would

eventually be called Al Gal 68 and the people who are working on this it's like a who's who of like computer science fame right so horror is on this and and so are a lot of other people like Nicholas Worth and that kind of people

like 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

ever before. I have no idea who this guy is. And I'm like, wait, what? And oop,

is. And I'm like, wait, what? And oop,

sorry. And when was talking about it was like oh you know in some private correspondence because Alan Blackwell and Carrie Roden not really a part of the story but they're like we talked to

her privately about where we 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 okay so what's this about? And Ross had this thing he called a plex, which is a record-l like data structure. And

apparently this was something that really influenced uh horror's record handling paper, which would eventually go on to in you know 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 object Objective C if there are some still 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 programming. Small talk was very

programming. Small talk was very important. It's influential at least in

important. It's influential at least in the research or in the understanding of oop right it was a very pure oop language. It it pushed oop a lot further

language. It it pushed oop a lot further than a lot of the 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 it's everything's

object oriented. So it's everything's going to be like small talk which is what objorinted was right if you look at what Alan K talks about for his inspirations like where did he get his ideas from small talk he list some

things and there's some like the burough's 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 huge

hugely impactful thing for Alan K. And

Sketchpad was like this drawing program, right? I was aware of Sketchpad. I mean,

right? I was aware of Sketchpad. I mean,

maybe some of you are aware of Sketchpad. It's pretty famous. You can

Sketchpad. It's pretty famous. You can

look up demos of it on YouTube, for example. So, we've got this Ross guy

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 got this Sketchpad thing. And I'm like, hm, I

Sketchpad thing. And I'm like, hm, I think I remember Sketchpad, but I don't really know why that would have inspired Alan K to do object. 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

further. 1952. Now, there's this place called the Servo Mechanisms Laboratory at MIT, which is kind of an amazing name. Um, I would love to be able to

name. Um, I would love to be able to tell people that I worked at a servo mechanisms library, uh, a laboratory rather. But this fellow right here, that

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, you know, 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

make it. It's almost like the birth of like 3D printing. And they actually did demos of this. They had stuff working where you could like type in a description of an ashtray in like the sort of pseudo language that they had

that was meant to be kind of more uh it's sort of, you know, uh almost like in a Gracehopper sense, right? 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 right I mean until a 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 it's not entirely they've got it working they have uh instances of objects you can actually look at that they made so they're 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, right? So,

they're working on this this simulation stuff that I'm sorry, this uh this processing stuff and this where they're trying to take language and turn it into uh sort of CAD, right? The birth of CAD.

And just to show you how early this is in the thinking about what's going on in computing, cobalt is generally like again in the kind of uh loweffort Wikipedia search version, cobalt would

be the first thing you'd see referenced as having things like record-l like strrus, right? Like we all take a

strrus, right? Like we all take a strruct for granted where like a strruct is like the simplest possible thing, right? It's not doesn't have inheritance

right? It's not doesn't have inheritance or it doesn't have uh virtual function calls or any of that stuff. we would

just say, you know, if we're just talking about a bare strct, a basic vanilla strruct, that doesn't really exist. Like no one's thought about that

exist. Like no one's thought about that really. They have sort of an idea of

really. They have sort of an idea of data records that comes more from like data processing, like the old IBM sense of the term. So they do have an idea of like more of like 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 implication of this program I've defined other records They're not thinking about that. And

even in this in 1960 when this was uh printed, this first version of Cobalt, even in that 1960 time frame, this Cobalt didn't really have that. All of

its record stuff was pretty much still about data on tape kind of things. It

was 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're just think of it as storing data. Now pedance will

say that plan calcul 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

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 like put multiple things. It's

like no matter how rigorously define it 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 it's kind of not there at the time. So what people are actually

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 it gets published officially

as well. It it gets published officially in 1960 in this paper by John McCarthy who obviously was one of the uh I 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

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 okay we're going to have like a 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 they're

right? Because again there's they're like no high level languages. We got

like forran coming in this time. We got

list coming 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

Douglas T. Ross he's also working on stuff like this. They have a programming language that they're working on for this you know computerated modeling stuff that they're doing. and he's

actually thinking what if we did structured data like 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 list 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 like

structures of like 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,

in there. And that's no good either, right?" So, he is 100% on point. And

right?" So, he is 100% on point. And

this is published in 1960.

Contemporaneous with the list publication, contemporaneous with something like Alol 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. 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

self-promotion. He never gets this term to stick anywhere. So, you know, 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 struck 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

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

plex. This is in the original paper in 1960. And what does it have in it? Well,

1960. And what does it have in it? Well,

it has some data, an x and y coordinate for example, right? Just things that you might store like you would normally data members. It also has pointers already,

members. It also has pointers already, right? These are basically things that

right? These are basically things that are linking it to other things. So,

we've got data members, we've got linkage members, and hold on to your butts because what is this stuff down here, right? Like, what is that? And I'm

here, right? Like, what is that? And I'm

loving this, by the way, when I find this stuff in papers, right? Because I

don't like to just read the abstract. I

want to read the whole paper. Like, 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

right now. So, I'm looking at this, I'm like, "What the heck is that? TRA 562

like 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 subruine and just

way. We could run one subruine 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 it to go through a particular path, we don't set it. Right?

Just pausing for effect on that one.

What's 562? What's 467?

562? What's 467?

Those are addresses. That's an

instruction. It's saying what we're going to do there is jump to a subruine.

Those are function pointers. So we

basically say sometimes we don't really want parameterization of what's going to happen. We just want a completely

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 Struck, we started in 1960 right here.

We're We're like We're like the old sort of uh thing at a university, like the you know, the old sort of uh the club, right, that's been going forever. We We

got roots, man. We got roots. We 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 you 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

engine." So, we're trying to think about things. How do we model lines? How do we

things. How do we model lines? How do we model surfaces? That sort of thing. He's

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 like connect it 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 off the charts with what they were

doing. It's kind of crazy but doesn't

doing. It's kind of crazy but doesn't stop there. So that is at the servo

stop there. So that is at the servo mechanisms lab which later gets renamed to like 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

name. I think it might have said it was even one of the longest running labs.

Anyway, so hardcore, but there's another MIT uh sort it's sort of like it's not on the main campus in Cambridge. It's

off in Lexington. It's called the Lincoln Laboratory. Also very prominent.

Lincoln Laboratory. Also very prominent.

And this is the other side of a story.

Remember I said we have this thing where C Horus is saying, I got these ideas from Ross. He was pretty cool. And then

from Ross. He was pretty cool. And then

we also have that Allen uh that Alan K part where he's talking about hey sketchpad. So we haven't talked about

sketchpad. So we haven't talked about the sketch part. 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

wolf style. and he comes to the Lincoln laboratory in the summer of 1960 uh as an intern originally but he ends up

doing his PhD uh at MIT here. So this is what he's doing. And in the course of there's these computers called the TX series. There's like TX0 and TX2 and

series. There's like TX0 and TX2 and they're basically made by this guy named uh Wes Clark is at MIT and they're like they're making the computers, right? I

mean that's the way this stuff worked back then is like the university actually had to make computers that they would use because nobody knows like what a computer even is yet and they're like building different versions of them and 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 like draw on a piece of paper is like completely unheard of.

Like 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

this guy who was architecting them, that Wes Clark guy, uh 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 like see what's on the CRT, and I'm going to like 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

I'm told. I don't know the story behind that, but he makes thing called the TX2.

And obviously when you make something like this, it's hard to get time on it because it's just there's this one that was built. But he makes this and it's

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 trans like large arrays of transistors for

computing like 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.

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 West Clark said yes because from then on Southerntherland went in at 4 in the morning because that was the slot that was open to work on

this thing. That's the TX2. And that

this thing. That's the TX2. And that

right there is the uh is actually Sketchpad running. And so he would work

Sketchpad running. And so he would work on this. And I mean when I say work on

on this. And I mean when I say work on this, you'll notice it's not like a keyboard here. You're not like typing in

keyboard here. You're not like typing in code into an editor. It was still like had to be manually entered in various ways, right? There was actually like a

ways, right? There was actually like a secretary who would enter some of it. He

entered some of it, right? It's like so it's very laborious to develop things in the 1950s. Again, just to kind of hammer

the 1950s. Again, just to kind of hammer that home, these guys did not have much to work with, but he's working on this sketchpad program. And what you could do

sketchpad program. And what you could do with it is stuff that we completely take for granted today as stuff you could just do. You could do things like draw

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

fairly intelligent. It knows things like snapping. Like if you go and you're

snapping. Like if you go and you're going to connect back to a point, it knows that it's it's not stupid, right?

So it's not just doing random line drawing. It's thinking about those lines

drawing. It's thinking about those lines as well. We'll talk a little bit more

as well. We'll talk a little bit more about that because there's a lot more to cover there. But Alan K, who I said was

cover there. But Alan K, who I said was the person who got us into this in the first place. The reason we're looking

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

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

probably right. Out of sketchpad comes a lot of research in computer graphics. It

comes the whole object-oriented concept from Alen K. Uh the the whole idea of interacting with 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

want to hammer home one more time the kinds of things that Sutherland talks about if you read about his experience with Sketchvad 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

line anymore. I could just move where it is. This is a completely new concept

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 to use a computer. The fact that you can move

computer. The fact that you can move things around by pointing at them, completely new. That's what we're

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?

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' group is working on CAD. They're not displaying much

on CAD. They're not displaying much about it, right? They're not working interactively, but they're trying to do these like 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?

Like, how do I do that kind of data modeling in the computer? Do you guys have ideas?" And Douglas Ross is like,

have ideas?" And Douglas Ross is like, "Have I got an idea for you? It's called

a Plex, right?" And as we saw, Plex is pretty awesome. And Ivan Sutherland is

pretty awesome. And Ivan Sutherland is probably one of the smartest people on planet Earth. So he recognizes right

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 like primitives, right? 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. Like I'm just going to have like lines and you know later uh actually it was Claude Shannon, the father of information uh theory,

right? Who says you should put circles

right? Who says you should put circles in it too?" So there's all these kind of like 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, right? 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 n component thing and I'll just have lots of those and that's how we'll do it. This is how I'm going to write the program. And here

is his diagram from his thesis about how he's going to structure, right? How or

how he did structure lines and points, right? And there's some information

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. Um, so

it's not completely documented in here, but you know, you can see here it's got the line, it's got a pointer to each of the points and so on and the coordinates sort of sketching that out. And hey,

it's exactly like that paper from Doug Ross, right? And Doug Ross published

Ross, right? And Doug Ross published this in 1960s. So Ross and his team were already thinking along these lines before Southerntherland even got to the lab, right? And started working on

lab, right? And started working on Sketchpad in the later a little bit later in the early 60s. So that's how this this whole thing ties together.

Ross and Sutherland are like 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 sub

jumps, right? They were like sub routines. They were the virtual

routines. They were the virtual functions at the time or we maybe would call them uh not so virtual functions, although you could implement that way.

We just called them function pointers, right? And you can do all the same

right? And you can do all the same things you can do with a function pointer. That was something that Doug

pointer. That was something that Doug Ross was talking about in his plexus 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 uh be completely specialized having having the routines completely specialized. So what

I'll do is I'll just have like a few entries in the data type that say how will I display it what's what would I jump to to display it to figure out how big it was or to move it. So again,

virtual functions right there. They come

from the plexes. He puts it in and that is how he actually implemented that kind of like parametric behavior in this program in 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, you know, I probably didn't have time to 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

this program. But in this one, those are actually space in the strct. Those

fields there, there's there's gaps, right? So, why are there gaps? Why are

right? So, why are there gaps? Why are

there gaps in this thing? And I wanted to know. So, I'm coming through this

to know. So, I'm coming through this like what are the gaps about, right? 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

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 37. What this means is

37. What this means is Sketchpad is on Steam Team Fat Struct 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? Uh, we didn't end up doing that." And so, he kind of just has

doing that." And so, he kind of just has that mentioned 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,

bending it a little bit there because it in the sketch 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

things. It's hard to tell whether or not he was using like things that always had fat strct or whether it was more like semi-istributed unions. So there were

semi-istributed unions. So there were pairs of things that would have been used differently. So it's either team

used differently. So it's either team fatstruct or team overlay fatstruct 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 doesn't go any deeper than this. This is where it actually started

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 CH horror. That Plex uh concept goes to him because they sit on the algo

committee together. So that's our first

committee together. So that's our first branch. We then have that horror paper

branch. We then have that horror paper was read by Dah and Nygard who decide to use it to create their simulass idea and both of those you know Simula and

Sketchpad influence Alan K to create the small talk branch of oop. Meanwhile the

experience with simula influences bejornstrip to create 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. It got multiple inheritance. Not right away, but it got

inheritance. Not right away, but it got it eventually. Small talk never did

it eventually. Small talk never did single inheritance.

However, single inheritance will get you C++, but it won't get you small talk. You

need two parents, right?

[Applause] What can I say? So, that's the actual end. Now, we've built our tree. We're

end. Now, we've built our tree. We're

finally done. We know where this stuff came from, right? It was long.

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 going to 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 and just, you know,

hierarchies." And and just, you know, 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,

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 uh stuff that

right? The looking glass uh 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. Like I am I am literally out of high school so I don't know anything. Like I I programmed a ton

know anything. Like I I programmed a ton as a kid but you know if you ask me you know uh 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

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. So the idea was you take these spheres and you build a level up out of like unioning them together, right? Like

a standard CSG modeling kind of stuff.

But of course I don't really know any CSG stuff. I have like really know how

CSG stuff. I have like really know how to do that. So I go using I think it was sightseer at the time like nowadays you might use like Google Scholar or something to search for papers. So I go to use like 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 you know not the internet's only been available to the public for a

short time really like was arponet you know until the the mid9s right so when when we're looking at this I go to crawl papers and I'm like okay CSG on spheres

like to try to type some things in read some papers you what am I going to do and I come across this thing called alphashapes and alpha Alpha shapes are just the name that someone in a paper had given us something that was basically implicit services. I don't

really know why they called alpha shapes because it escapes me now. I'm sure I knew at the time because I just read the paper, but for some reason they're talking about these alpha shapes. I

looked at I was like, oh, if it's like spheres, but when you move them together, they make this like nice smooth join. They don't make that hard

smooth join. They don't make that hard edge. I was thinking, oh, for levels

edge. I was thinking, oh, for levels that would be like really cool. That

might be like way better than if we did CSG on spheres because it would have this like really cool effect. So it was kind of be like on the inside of these things which are you know typically called metabols and it was going to be

like sort of the negative space of the metabols. So I made a modeler for this

metabols. So I made a modeler for this and I called it mega man which has nothing to do with mega man completely legally legally distinct from that. It's

kind of change one letter and maybe it's the same but nothing to do with this.

It's just negative space metabols. And

this is what it looked like. And

effectively what you did is you, you know, picked things in it. You can see those spheres there are metabols.

They're the kind of spheres you put together. And they form these kind of

together. And they form these kind of surfaces. And we're seeing the inside 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 metabol modeler.

But this is what I was working on. Well,

I I mean, and it's finished. Like you

can use it. I still have to this day.

You can model stuff around. It's it's

pretty janky, but it it does what it's supposed to do, right? And so the way that you interacted with it is you like picked those spheres and you could move them around by dragging the mouse and that sort of stuff. The same sort of

things, right, that like Sketchpad was doing only, you know, with much better hardware and and much more advantages in ter of development. Same kind of idea because, you know, like Southerntherland was so far ahead, right? And so if you

wanted to create stuff, you might select things like here. I don't know if you can see it. selected those two metabols at the top and then I've just like inst there's a thing you could like rapidly stamp them down. I kind of just drag them and 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 going to 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 want to do the interaction, it's got to make sense for what's going

on. And this is really tricky because

on. And this is really tricky because the inheritance thing doesn't help you at all for this. It fights you. You're

constantly like, "Oh, do I just add a bunch of like functions to the base class that's anything you might want to do to a class? Do you basically fatty structure interface, right, 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, you know, pretty gung-ho at the time. Uh, you know, I'm not old like I

time. Uh, you know, I'm not old like I am now. So, at the time, I don't mind

am now. So, at the time, I don't mind typing a lot. So, I go to town on this.

And I'm like, "All right, I'm going to try to figure out how to do this cleanly, quote unquote."

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

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

like that. It's just like you don't understand." It's like, "No, dude. I

understand." It's like, "No, dude. I

wrote some of the most ridiculous oop stuff you have ever seen when I was like 20. I was doing crap like this all the

20. I was doing crap like this all the time. It was awful. I'm not proud of it.

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 like I'm doing the implementation inheritance thing up there with with a template on the class.

This if you've ever seen this trick, it's an old school. So, it's like there's so much stuff in this codebase.

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

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

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 where is the camera?

Seriously, like I have done ridiculous oop stuff. You if you don't believe me

oop stuff. You if you don't believe me after seeing this, I do not know what to tell you. We can post more of this code

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

properties. It's just callbacks that would get and set the properties, right?

And then you know this this is what that class looked like, right? Here's the get and set callbacks abstracted into a property. And then if you wanted to use

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, right, to do the changes you actually wanted to do.

Okay? And that's to support like dragging and undo and things like that.

So this is what it looked like if you drew it out. I have a metabol and center. The data is in the metabol,

and center. The data is in the metabol, right? Just like a good object-oriented

right? Just like a good object-oriented programming uh thing would tell you to do. It's encapsulated inside the

do. It's encapsulated inside the metabol. I create parallel I call them

metabol. I create parallel I call them property universes. I create property

property universes. I create property universes. All of the center properties,

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 metabol.

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 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,

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,

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 like

anyway? because they must have had like 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. It's worth it.

Trust me. It could do a lot of other stuff than just draw. The just drawing stuff is the stuff that like 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

like. You could say, "I want these lines to be like perpendicular to each other."

And it would do it right. 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 right 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 Flint.

Right?

When you tell it those things, you say, "Okay, that's what I want my shape to be." It'll just solve it for you. And if

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, right? Using like a relaxation le squares kind of thing.

And I'm like, "What the heck?" I

remember this. It's, you know, because I'd seen this demo before. And I'm

sitting there thinking, you know, that whole compile time hierarchy thing and Allan Case like he saw Sketchpad and I I'd known those parts, you know, all the details I had to learn for this talk,

but like I'm like, what the heck did he do? He's working on this like crap

do? He's working on this like crap computer. I get that he's way smarter

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

he do? What does a really smart person do when they're faced with this situation? because he's creating stuff

situation? because he's creating stuff that people who came after him who have like crazy debuggers and wizzywig editing and the ability to run things quickly and iterate, he 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 uh 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

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 you know what am I actually going to be doing with this particular constraint. But they're relatively

constraint. But they're relatively generic in this way.

And then the things you could constrain, scalers, points, this is text, digits, and dummies. These are the different

and dummies. These are the different things you could constrain. They're sort

of all like again, you know, sort of uh almost team fat struck there, right?

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 looking, we were talking about here's how those lines of the line would not necessarily be something that was constrained, right? because it's kind of

constrained, right? because it's kind of a it's a bigger thing than these are. Uh

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

that way. And I don't know all the specifics of how the constraints worked 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

degree. So I can't give you a perfect breakdown of exactly every piece of the system, but I mind 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

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

satisfaction. So what is this ring structure? What does he mean by that?

structure? What does he mean by that?

But he's pinning it on that. He's like

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 origin that block which is kind of a type of ring structure, right? And he says this,

structure, right? And he says this, which really throws you for a loop when you're first reading the thesis. In the

data storage structure, the separation of general 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 ex essentially right?

So here is how the data is laid out. Type

is a chicken. Link quote unquote.

Specb is a hen. So now when we go back to this uh type that we've already looked at, we can see them up there at the top. Type is the chicken. Spec B is

the top. Type is the chicken. Spec B is the hen. This is sort of the workhorse

the hen. This is sort of the workhorse of the structural elements of this system. And the way that it works is

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 specb hen is the sentinel

doing. And the specb hen is the sentinel for the list of all the things that are like subordinate to this thing. So it's

like an up and down kind of a thing that's going on there, right? So chicken

and hen.

Here is how he actually draws it. You

can see it's just a like 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

okay. He then goes on to present this and this is the runtime structure of sketchpad. You start with a universe and

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

topos. The ones we care about in this case, we don't really care about the holders much for understanding. But the

topos are lines, 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 user interacting with. Um, at a higher level, the

with. Um, 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

can edit. The topos are made up of those variables, right? A line is made up of

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

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, right? And you can do whatever you want to those points without that thing even knowing that it

happened, right? So, it's almost like

happened, right? 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, oops. Well, it kind of looks like this,

oops. Well, it kind of looks like this, right? The topos, you have a circle.

right? 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 scalers. Those are the points. And if we

scalers. Those are the points. And if we have something like constraints, it's going to operate on them. It just points into those things. And all of these pointers are typically like birectional.

Like that ring structure is allowing you to walk in both directions if you want to, right? But this is the way that

to, right? But this is the way that you're actually like 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, right? in this generic way that operates

right? 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 ND 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 ubo. It's just where are the encaps those encapsulation boundaries, where are the boundaries, right? Instead of looking at it and

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

right? The ability to say if I want to draw this a different way, I change the sub routine." Now, I'm not trying to say

sub routine." 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 going to get you the simple stuff. The only reason that even worked for Southerntherland in the

display case is because his display was simple. He didn't have to do things like

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

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

have 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 Alen K, father of small talk and this quote breaks my heart because I like Alen K. I think everyone likes Alen K probably. I don't know maybe not

K probably. I don't know maybe not probably someone out there who hates Alen K. Alan K is very sorry. He was

Alen K. Alan K is very sorry. He was

trying all sid kinds of cool things.

Xerox Park is awesome. I'm not gonna say something negative about Alen K. 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

knew about. So he because I happen to know that Alen K read the thesis that's documented. Alan K says he read the

documented. Alan K 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 omnisient he was calling it

omnisient right this idea that it could look at the properties like that and work on them and K thinks it's a bad thing right he says hey there's this thing called Alan Bing's thing lab which

is another program that was made later a first attempt to go beyond touchpad and he devised a nice approach for dealing with constraints that didn't require ire the solver to be omnicient.

The omnicient part was the good part, right? That was the thing that was so

right? That was the thing that was so powerful. It's why it's kind of

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

little objects. So why did they why was Alen K so focused on that stuff? Why was

Strus so focused on that stuff? And

honestly, from reading it, oops, didn't mean to advance there or to go back there. From reading it, this is my best

there. From reading it, this is my best guess. Their backgrounds predisposed

guess. Their backgrounds predisposed them not to want this, right? You look

at where they come from. Strus comes

from distributed systems. Alan K 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 Allen K especially that that is the future of how we will engineer things. They're going to be

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 microorgans. And most of Alen K's ideas actually map very well to things like the internet at large where you really do have to just pass messages back and forth. So again, not going to

say something negative about Alen K. The

ideas are good and they do have very good applications. It's it's smart. It

good applications. It's 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 us 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 hard stuff wasn't very good. One of the things that I didn't really appreciate was it kind of sounds to me like shrusup

was really important in getting type checking for us. Like C did not even type check function calls at the time that was making C with classes, right?

And he recognized because of his background in simula. He's like this is ridiculous. I think he gave an example

ridiculous. I think he gave an example like if I do square root like sqrt in C parenthesis 2 that doesn't work right now because it passes the integer too and it doesn't

check that square roots taken a double or something right 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, you know, 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

right? And it's not like we can't think of uses for things like virtual functioning classes like interfaces just that bare concept is a place where we still use those things today even new

languages those things. So there there is that too if it's used responsively, right? It's just that compile time

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 credit. He's also on the same team. He wants the fast thing,

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 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."

right. I get it. I get it, man. I do."

So, that's the 35-year mistake is 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

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 you 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

comics. Maybe that's a thing. Hit number

two, Java. OOP. This is from W3 schools.

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.

Strus talks about vehicle 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?

And don't ask me why there's spaces in that and not in the mountain. I mean, I don't even know. That's the top three hits. I stopped looking after that

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 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. Right? We got

this thing in place. There 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 must be doing it wrong, right? But actually that wasn't the

right? But actually that wasn't the case. And

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 K. He's

the one who said it, right? That's him

sitting at his uh you know I think that must be uh one of the original Palo Alto computers right the Alto I think is what that one is from Xerox Park.

So that's the actual end of my talk.

Thanks everyone for listening. I'm

surprised I was able to remember all that stuff for this. You've been a wonderful audience and uh I guess now Ryan Flurry will be coming up on stage

to uh interview me and take questions from the audience. Is this correct? Sam.

What? Sam, is that true?

I say it again.

The organizer, ladies and gentlemen, please welcome to the stage Ryan Flurry.

Everyone Okay. Well, yeah, thank you for that

Okay. Well, yeah, thank you for that talk. That was really good.

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 reemergent. It kind of makes it feel

reemergent. It kind of makes it feel like there's like uh maybe like some degree of gaslighting 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. Uh 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

this case. He honestly believed that having the thing be omnisient was bad.

He's saying that this is bad. Right? And

you see the same thing from Strereip saying that this you know switch you know this basically switch on a type is bad. And so I I think they just honestly

bad. And so I I think they just honestly believed 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 this thing that you

propagated. This is this 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 um in your own personal programming like journey you started with like learning the traditional object-oriented sort of or like C++ templatization of uh

compile time hierarchies of encapsulation and so on. you uh I mean I I have an idea of where you changed 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 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.

Right. I didn't know any of the things.

I wouldn't know anything about architecture. C++ wasn't even invented

architecture. C++ wasn't even invented uh in the in I don't think would it have been invented? So C so C with classes

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 uh I I definitely

like thought that everyone was presumably 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 the gathering. It's

something people made up that was fictional but you you know you don't know that. you think it's real, right?

know that. you think it's real, right?

But you're getting into it in the same way you might get into Magic the Gathering, like, "Oh, I figured out that the template can do this thing and it becomes its own little game, right?" So, I think it kind of went that

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 had actually thought about it, but I chocked 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,

actually true. I think it was just like, "No, these are actually just worse than what you were 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?

Uh 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

they 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

programmers. So maybe it's not the case that I just don't understand it. Maybe

there's actually something to keeping 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 wouldn't never had 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 simula was a thing

stuff, right? And simula was a thing with papers and stuff like that. But the

person who learns to program like you know in the game industry and stuff like that the person who learns to program on an Apple 2 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 plexes 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 that idea pushed down on them in a way that they believed.

Okay. Um, so, uh, I had it in my head, but I got to check my notes here. Um,

so I think that I'm I was curious about I have a collection of like not exactly related questions or discussions like hit me.

So, one of the thing you introduced this subject by saying like one of the arguments that people will use to promote like sort of object-oriented these or I shouldn't say object-oriented, I should say compile

time hierarchies. If someone out there

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

uh and it would be nice because again, like I said, I think it's pretty important to draw that distinction because like like Mach who I quoted at the beginning of the thing who did that entity

component system, he's like he's thinking of it in terms of object-oriented. He's not thinking this

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 codebase and just not think about that compile time thing. And it seems to work pretty well.

Yeah, it kind of seemed like um the object-oriented part of drawing boundaries, it doesn't actually it's not um it might be descriptive of a system, but it's not prescribing like 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 a

about, right? I don't know that a a hardcore object-oriented uh person like certainly not Alan K 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 objective 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 like what that

size is so on the large team subject you were digging through all 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

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 I

what I can tell you so I don't know that's another that'd be a whole another topic. This thing took two hours or

topic. This thing took two hours or something like that, right? So that's a whole another 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 things 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 simulus side.

like some of their opinions may have been influenced by uh 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 simul in the world had something to do

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 the history of computing it's always large team or small teams pushing large

improvements like successively so it's interesting to optimize for large teams that in that way but 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 uh 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 our risk comes these few people doing something, they're not having the same experience as a large

team. So maybe it's like small teams

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.

innovation. I don't know.

Yeah. Um, so I'm kind of curious about like so a few uh programming ideas that a lot of people use like that you regularly use in your in your

programming came up. One being like discriminated unions or tag unions um as sort of like forming this like mutually exclusive branching structure um as

opposed to uh like the fatstruct model where it's like a comp just it's one unified type. I'm I'm kind of interested

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

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 fatstruct 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

distinct. I think of them as sort of the same things. I'm just trying to use

same things. I'm just trying to use terms that other people think in to communicate that. So the way that I

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

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 oop side of things because I'm like I see why you guys are 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. So I 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 going to be adding types to the system more frequently or whether they're going to be adding actions. I tend to find that people add actions more frequently.

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 exact same reason for true strip and everybody else to catch errors. I

don't want to be using I don't want to make that a fatty strruct where I'm accidentally doing code that's going to do both things. So I try to basically replicate that simul style thing or really it's it's Tony Horses right sir

Tony idea of of that I try to replicate that and it's just unfortunately C++ has doesn't really have good support for that like I said Santa very is not very good in my opinion the real thing that Tony Horror

wanted would would have been great so I would love that feature the fatty strruct qua fatty strruct and like I said I mix these two together so I don't think it's that distinct to me but the idea of like feature flags or something like that right like I'm going to hit

this bit and then it means that this path might be taken. What the Plex guy uh right what what Doug T. Ross would

have called those like switches, right?

That to me is for mixin as they call it, right? When I know I'm combining lots of

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 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

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 would it would take in 30 minutes.

Yeah.

Right. Yeah.

And I I'm I'm a little confused about the uh like exactly what so looking glass you introduced them as using like sort of the faststruct model, but it sounded like they ended up with a entity like

component system thing where they split everything out into like they 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?

Uh 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 the the split point is in about 25 minutes.

Uh, how badly do you want a complete version of that answer versus a summary answer? Because I can answer

summary answer? Because I can answer that very accurately.

Okay. Um, yeah, let's go with the accurate one. Okay. All right.

accurate one. Okay. All right.

[Applause] deleted scenes to keep this talk uh 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

relatively quick. So, inside Ultima Underworld, an entity was basically a fatty strruct 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

and lanterns don't have hit points, then we'd put them in the same place, right? That was that was uh Ultima

right? That was that was uh Ultima Underworld, right? And of course, this

Underworld, right? And of course, this is, you know, rough because it's like it means that when you're accessing one of these, you're secretly also accessing the other, right? because they're in the same place. And so you could have an

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,

fuel. And then you delete the entity, you know, because that's what it was thinking, right? And this is Mach. He

thinking, right? And this is Mach. 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 Ultima Underworld 2 and he's the one who coined that phrase that that quote I put up. That's him, the compile time harchy. He's the one who

crystallized that, right? He comes on cuz the uh in the earlier earlier ones like it was Doug Church and Dan Schmidt and a bunch of people who did Ultima Underworld one. He comes on of

Underworld one. He comes on of Underworld 2 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

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.

Nice.

Right. And so he had to fix that bug by doing exactly what you'd expect. He'd

have to like check, you have to manually add that code.

Yeah.

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 Melon 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

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

right? they just don't know what else to do because they have these like really hardcore memory constraints.

Yep.

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 that needs to 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 Ultimal Underworld one two and they do System Shock. I'm just following their lanes. They also they have

their lanes. They also they have Pteranova 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 uh doing RPGs. This is just the RPGs from looking

RPGs. This is just the RPGs from looking glass. Um, so yeah, it kind of looks

glass. Um, so yeah, it kind of looks like that. I'll skip this because it's

like that. I'll skip this because it's not part talk. Uh, they go to an outlinking kind of structure. So what

they do is they say, "All right, we we kind of want something better than that.

So we're going to do is we'll have our entities. We have a little bit more

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

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? Because they can't

limitation, right? Because 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

got there. That's that's what system shock was. It was like one outlink per

shock was. It was like one outlink per entity that could extend it.

Got it.

And now that solves their growing problem, right? It's like we can just

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 then I it's kind of more

source. And so then 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 this because it it sets up the entity component system thing. Flight Unlimited actually had,

thing. Flight Unlimited actually had, uh, 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

memory. Totally like thrashed out memory and fragmented memory. So, uh, I don't know if this is well known, but basically Fight Unlimited is a game where you like fly around, you know, in the thing and and whatever. It was very popular flight at the time, actually.

Uh, 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

stuff. There's no fuel gauge at all. But

sometimes it would say out of fuel would just be like out of fuel, right? And

what out of fuel was was actually the memory is too fragmented. So what it would do is it would say out of fuel, it would clo it had like a 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 you save the game

the executable. So you save the game state, close the executable, reload the game state, and you know, then you were there you're back to good. Uh this is Tom Leonard. So thief of dark project

Tom Leonard. So thief of dark project comes on the heels of this. This is Tom Leonard. He's actually the guy who as

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 the 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

model switch. And I didn't really call again too much stuff getting cut that we're going into now. So, you know, I guess six of one half dozen the other.

But the idea of saying, okay, instead of entity.get hit points, we're going to

entity.get hit points, we're going to say hit points.get entity. This is a big like that's a big switch if you never thought about it before, right? He'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.

It's like now instead of having like either tons of functions like get a hit points like thing, get a this that are on you know an entity which would suck.

Now, we just ask the actual thing, the hit point system, and it's only going to return one type, which is like a hit points type to us, right?

Um, 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 uh Flight Unlimited. They want arbitrary

Flight Unlimited. They want arbitrary sized properties, right? Because they

don't want to make those trade-offs between combat systems and fuel and whatever. They also had additional

whatever. They also had additional things which is like they wanted designers to be able to create types at runtime which the so they kind of want bags of properties that they can have designers create and they want designers

to be able to do things like create domain mile um uh 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 they do those

way. Right? So they they do those things.

And then finally the how fast is the fastest case thing. Uh that was from Doug Church. He was like, "Okay, if

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 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. That 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 uh object system if you want to create a property type, right? It's like

I said, it's still oop 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,

think. So, it's like again, not not oop, it's just not that uh hierarchy thing, right? Yeah. So, so there you go. I

right? Yeah. So, so there you go. I

think that's everything.

All right, let's see what else I've got.

Um, yeah. So I guess um

yeah. So I guess um one interesting thing about what you were saying is that what it has to do with like the 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 it's 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 is 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 ar like the problem

doesn't arise from it or whatever or the or the you know it doesn't arise from the problem I think is how you phrase it. I think a person who thinks in terms

it. I think a person who thinks in terms of object-oriented programming and is an afficionado 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

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,

right?

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 Flurry.

Right? 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 get

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

like. It's not what it is under the hood." Then I think I'd be right there

hood." Then I think I'd be right there with him. Right.

with him. Right.

So, interesting.

Um, all right. 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.

Um, okay. I had two pages. Uh,

I did that one.

Oh, yeah. I guess another thing. So, I

guess I 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 uh introducing these boundaries between parts of your program when when you could have not done that in the in the architecture but you did for one reason

or another. Um the interesting thing is

or another. Um the interesting thing is that you were talking about sketch is it sketchpad? Yeah sketchpad. it you have

sketchpad? Yeah sketchpad. it you have some layer which is like quoteunquote omnisient 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 help I haven't found that to be helpful

because of you what you have taught basically but but I'm but 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 full

disclosure, right, folks at home.

Seriously, like it's insane. So, you

don't need me to tell you what to do.

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

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

documented. I mean if I can go figure out most of it now looking back at the than at the time when you could have actually talked to Ivan Sutherland fresh off of the implementation where he remembered it all right.

Um 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 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 for people to use in cases where that aren't

as hard. But it's almost impossible to

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

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, 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

architectures. That's my feeling about it. Anyway,

it. Anyway, do you blame uh Y Combinator at all for like the internet or I'm about to blame them when I see what they post about this talk and somehow managed 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,

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 know like well I don't know you've said it 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 it's a wall you're introducing that makes something more difficult and so if you put that right into the middle of your of the hard problem like you say yeah

and I think the 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

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 where 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 procrustian it's like this oneizefits-all approach that I don't think really even fits that many problems but it certainly doesn't fit uh

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 a

fixed model in mind and if that intent leads you to a very unus usual 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, then then you should do that.

You should follow that sort of weird structure because that is probably right.

Yeah, that makes sense. Um, okay. Well,

I've I think I've exhausted all the all the questions or 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 the Well, we we can do one we have maybe five minutes.

Okay. Okay. Shoot. Sorry. Sorry

everyone. Um okay. Uh Rafael, do you have a do you have a question? You can

just speak out.

Yes. like um if we had the solution in the 60s and we saw the power of like sketchpad and like why was let's call it

dark oop still able to gain foothold and catch on and suppress the good solution was it because was it a successional knowledge transfer problem or was it just because dark oop is such a catnet

for programmers because lots of interesting problem how do I represent that or like or or was it something else like why does it catch on I mean it's very speculative to try and Yes, something like that. Obviously, uh

I think you touched on some of the answer there, which is that like I do think people want to divide things into hierarchical categories kind of naturally. I mean, we did that with the

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, you know, DNA or anything like that or or how, you know,

uh 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

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 wizzywig architecture, like what I see in the real world is just what the code looks

like and we're done, right? Um, so 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 like 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

right? One of the reasons we got the sort of compile time hierarchy thing is because that's what stretrip kind of took away from simula. It's 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 typeing thing. I use simul was kind of cool. He

thing. I use simul was kind of cool. He

did the work, right? Um I mean, you could say that about uh 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 popular, somebody has to build Rust first. Somebody has an idea of what it's

first. Somebody has an idea of what it's going to be. Is that idea good or bad, who knows? But in order for it to even

who knows? But in order for it to even get judged in the marketplace, somebody 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 like

virtual dispatch basically. And you know I didn't go into the talk but Allan 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 uh but they were in that quote I said we're not going to cover them. They're like the Burrows 5000 series computers. Uh, and

the there's this Air Force this guy who wrote a file system thing where you put the like way to way that you use the files in the file system were sub routines that were stored in front of

the files in the file system. So it's

kind of like a virtual like dispatch thing.

The Burough's 5000 system also had this kind of virtual dispatch where there were like tables and things. And so for Alan Kay, who we didn't really cover in here, there 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 Burrows 5000, that Air Force thing that I thought was cool. Uh,

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 molecular biology and this messaging like you're going to respond to these messages. That's what these

dispatches are. or they're like how

dispatches are. or they're like how you're responding to different messages and he just goes down that path because he's he's thinking that that's the core thing, right? Because he's presupposed

thing, right? Because he's presupposed to see it because he's encountered this idea multiple times and so he's predisposed I think to 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 it I just randomly kind of stumbled upon this like oh wow wait okay like that's really kind of interesting sort 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 a 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 it's just not it's

just not plausible, you know. It's not

plausible. It's a hindsight thing.

Yeah, I think. Sure.

I think. Sure.

Um uh 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

from school. It was my pattern too and it seems that it's yours, right? You

learn a certain way and in school everything is kind of tied to business stuff, right? So it's it's very easy to

stuff, right? So it's 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 us 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?

problem? How can we improve this?

Because it kind of feels like you're trying to get smokers from stop smoking long after they're smoking. You know

what I mean? So you're

Well, I guess I would say you're at the right conference. I I mean that's like

right conference. I I mean that's like right 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 that's it you know I mean that's the

best you can do is put these ideas out there uh suffer the hacker news thread that you will then have to uh endure right 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 there is coffee we're going on break now we'll be back at 20 or dense.

All right. Uh well, hope I I will be in the audience uh anxiously watching this talk. This is this is from Tearown,

talk. This is this is from Tearown, right?

Uh I think so. Yep.

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.