Thanks for this! It presented your thoughts on the problem with OOP in a very clear way along with the historical reasoning. I enjoyed it all and would definitely love to see more of your insights presented in this clear way.
Your talked reminded me of a few things I read / watched that I would love to get your thoughts on:
In the talk you've mentioned that you haven't found any evidence of OOP justification from the stand point of helping large software teams be more productive. This reminded me of David Parnas'es paper "on the criteria to be used in decomposing systems into modules". It deals with information hiding (encapsulation), not OOP. In that paper, Parnas proposed that in order to allow parallel development of sw modules, modularization should follow information hiding. Modules should hide decisions that are likely to change from other modules, as opposed to a way of modeling the problem domain. What are your thoughts on this criteria?
I think Alan Kay was saying in some talk that objects should probably be much larger than they usually are commonly. I think this idea, if I remember correctly, aligns more with your thoughts on where should the encapsulation lines be drawn.
Can you please point to a reference or elaborate on the idea of a fat-struct?
In the vid you praised the use of discriminated unions. Could you give and example of how you use them and any advantage you gain from them. Thank you in advance
Great talk, I really enjoyed it! It’s not that common to see computer scientists or engineers diving into History. What you did is something historians would call the History of Ideas, a field that explores how concepts and ideas are shaped, not in some abstract or ethereal sense, but by actually understanding the real conditions in which those ideas were born or redefined.
It’s not just about how concepts like classes were invented or used, but about the context in which they were developed. For example, you mentioned how the design decisions behind Simula and C++ (Classes) emerged because the creators were dealing with a specific problems in simulation and distributed systems, and needed ways to model those *particular* problems. Or how Sketchpad’s data structures were shaped by the fact that Sutherland and Douglas were physically working in the same lab and their problems required plex like structures. These ideas weren’t born in a vacuum — they were responses to concrete problems, developed by people working under very specific historical and technical conditions.
Once again, I really enjoyed the talk , I’ll definitely have to rewatch it a few more times. What I took away from it is that there’s no one-size-fits-all architecture. We need to stay flexible and focus on designing architectures that actually make sense for the nature of the problem we’re trying to solve.
What a wonderful talk that was, such an amazing energy, I loved every second of it. Every time there was a slide “The End” I was like “PLEASE DON’T BE OVER!!!”
Although, to be honest, some parts went over my head, I think I was unfocused. It was hard for me to grasp those diagrams with relationship of data (about encapsulation).
For a talk that lasts almost two hours and goes over decades of programming history, the adjective "epic" would, for once, be actually warranted. Found it quite interesting!
I had some ideas rolling around in my head about a similar presentation, on various ideas in computer science that have been lost in translation, or otherwise corrupted. There are a surprising number of them! Hungarian notation is probably a more known example, thanks to Joel Spolsky's post on the matter. "Premature optimization being the root of all evil" is on average taken so wildly out of context it basically flips its meaning as a result. In enterprise Java, accessors are firmly entrenched as a default, despite starting off as a workaround for the language (initially) not having support for annotations. And so on, and so forth.
It seems that programmers have an uncanny talent for taking a good idea, horribly misinterpreting or twisting it, then running with _that_ as far as they possibly can.
I haven't heard your talk yet, so I am just responding to the topics of the post here, but re the earliest notion of organizing programs around data structures, I cant help but think those ideas would be present in the genealogy of LISP.
Ross and McCarthy were contemporaneous, but AFAICT only Ross figured out the in-memory layout part. LISP was still inferring structure from generic list primitives. Ross actually throws shade at its inefficiency in the opening of the seminal Plex paper :)
Oooo, gotcha! I was thinking "program organization" in a loser sense, at the level of the source language. Yeah, straight LISP implementations sidesteps the whole thing by saying everything that isn't a word is a pair of word + pointer to next word. 😅
I would love a livestream where you dive deeper into this!
A live stream deep dive into your talk would be very cool!
Loved it! would love nothing more than a deeper dive into some of the esoteric stories that didn't make it into the main talk
Yes, please do a stream!
Thanks for this! It presented your thoughts on the problem with OOP in a very clear way along with the historical reasoning. I enjoyed it all and would definitely love to see more of your insights presented in this clear way.
Your talked reminded me of a few things I read / watched that I would love to get your thoughts on:
In the talk you've mentioned that you haven't found any evidence of OOP justification from the stand point of helping large software teams be more productive. This reminded me of David Parnas'es paper "on the criteria to be used in decomposing systems into modules". It deals with information hiding (encapsulation), not OOP. In that paper, Parnas proposed that in order to allow parallel development of sw modules, modularization should follow information hiding. Modules should hide decisions that are likely to change from other modules, as opposed to a way of modeling the problem domain. What are your thoughts on this criteria?
I think Alan Kay was saying in some talk that objects should probably be much larger than they usually are commonly. I think this idea, if I remember correctly, aligns more with your thoughts on where should the encapsulation lines be drawn.
Can you please point to a reference or elaborate on the idea of a fat-struct?
Thanks again for the great presentation
In the vid you praised the use of discriminated unions. Could you give and example of how you use them and any advantage you gain from them. Thank you in advance
Great talk, I really enjoyed it! It’s not that common to see computer scientists or engineers diving into History. What you did is something historians would call the History of Ideas, a field that explores how concepts and ideas are shaped, not in some abstract or ethereal sense, but by actually understanding the real conditions in which those ideas were born or redefined.
It’s not just about how concepts like classes were invented or used, but about the context in which they were developed. For example, you mentioned how the design decisions behind Simula and C++ (Classes) emerged because the creators were dealing with a specific problems in simulation and distributed systems, and needed ways to model those *particular* problems. Or how Sketchpad’s data structures were shaped by the fact that Sutherland and Douglas were physically working in the same lab and their problems required plex like structures. These ideas weren’t born in a vacuum — they were responses to concrete problems, developed by people working under very specific historical and technical conditions.
Once again, I really enjoyed the talk , I’ll definitely have to rewatch it a few more times. What I took away from it is that there’s no one-size-fits-all architecture. We need to stay flexible and focus on designing architectures that actually make sense for the nature of the problem we’re trying to solve.
What a wonderful talk that was, such an amazing energy, I loved every second of it. Every time there was a slide “The End” I was like “PLEASE DON’T BE OVER!!!”
Although, to be honest, some parts went over my head, I think I was unfocused. It was hard for me to grasp those diagrams with relationship of data (about encapsulation).
Anyway, I want to rewatch it again :)
this might just be my fav piece of ce content so far. so cool to see the history of all of this.
For a talk that lasts almost two hours and goes over decades of programming history, the adjective "epic" would, for once, be actually warranted. Found it quite interesting!
I had some ideas rolling around in my head about a similar presentation, on various ideas in computer science that have been lost in translation, or otherwise corrupted. There are a surprising number of them! Hungarian notation is probably a more known example, thanks to Joel Spolsky's post on the matter. "Premature optimization being the root of all evil" is on average taken so wildly out of context it basically flips its meaning as a result. In enterprise Java, accessors are firmly entrenched as a default, despite starting off as a workaround for the language (initially) not having support for annotations. And so on, and so forth.
It seems that programmers have an uncanny talent for taking a good idea, horribly misinterpreting or twisting it, then running with _that_ as far as they possibly can.
Stellar talk, thank you!
<3 on having a continuation livestream
I haven't heard your talk yet, so I am just responding to the topics of the post here, but re the earliest notion of organizing programs around data structures, I cant help but think those ideas would be present in the genealogy of LISP.
Its from the 50's as well.
Ross and McCarthy were contemporaneous, but AFAICT only Ross figured out the in-memory layout part. LISP was still inferring structure from generic list primitives. Ross actually throws shade at its inefficiency in the opening of the seminal Plex paper :)
- Casey
Oooo, gotcha! I was thinking "program organization" in a loser sense, at the level of the source language. Yeah, straight LISP implementations sidesteps the whole thing by saying everything that isn't a word is a pair of word + pointer to next word. 😅