OOP History from gamedev perspective :)

[Quang]

Interesting video about history of OOP.

https://www.youtube.com/watch?v=wo84LFzx5nI&t=9s

Some claims from the video:

1) OOP started from the need of types

2) code reuse

3) solo dev first

[Quang]

main issue:

compile time hierarchy of encapsulation that matches domain model.

[Raoul Duke]

(reminds me that i  sure wish LtU wasn't dead, there was a lot of very good food for thought there :-)

https://www.google.com/search?hl=en&q=lambda%2Dthe%2Dultimate.org%20dbarbour%20tax%20oop

paraphrased: if you write a tax processing system in oop your main internal important objects should/not just be "the 1040EZ form" etc. 

[James O. Coplien]

OOP started as an experiment to build a minimalist programming environment in the 1970s. It eventually grew along with a design philosophy that guided the formation of objects by end user mental models (which have a relationship too, but are much broader than, domain models.)

The building blocks were objects, and I think the original philosophy was much more like that of the self language than of C++. That is, types were irrelevant. Classes were added as an efficiency for code generation. Types were not the origin of objects. OOP origins lie in Papert's development psychology, working with education systems that would allow children to connect with and explore their environment. Objects corresponded more or less to the "frames" that were popular in cognitive modeling around the U.S. East coast at the time.

Types did figure more strongly in the origins of abstract data types (ADTs). and when many people say "object oriented programming" they mean programming wth ADTs. This was what most of the C++ language popularity and evolution was about, thought its origins lie in simulation and in more of a messaging-based computation paradigm. I was using a version of C++ that supported that model with a task library as recently as 15 years ago, but don't know if such a package is still available. The current C++ standard neither supports nor prevents it.

OOP basics have been around much longer than video games have had any market footprint.

--
You received this message because you are subscribed to the Google Groups "object-composition" group.
To unsubscribe from this group and stop receiving emails from it, send an email to object-composit...@googlegroups.com.
To view this discussion visit

https://groups.google.com/d/msgid/object-composition/CAJ7XQb7EmR5gW9bcLEiuTXY7RwkhJM0twF0STmbiLZPkYNCsjg%40mail.gmail.com

.

[James O. Coplien]

OOP arguably goes back to Simula/67 and perhaps earlier versions of Similar. The goal was to create a project to get research funding to support an Algol compiler project, The project evolved into Simula, with classes that could be used as templates for actors in a discrete event simulation. We find a foreshadowing of messaging but the type system was largely an extension of the Algol framework. The type system innovation in Simula was a baby step into a run-time type system.

The West Coast school of OOP started as an experiment to build a minimalist programming environment in the 1970s. It eventually grew along with a design philosophy that guided the formation of objects by end user mental models (which have a relationship too, but are much broader than, domain models.)

The building blocks were objects, and I think the original philosophy was much more like that of the self language than of C++. That is, types were irrelevant. Classes were added as an efficiency for code generation. Types were not the origin of objects. OOP origins lie in Papert's development psychology, working with education systems that would allow children to connect with and explore their environment. Objects corresponded more or less to the "frames" that were popular in cognitive modeling around the U.S. East coast at the time.

Types did figure more strongly in the origins of abstract data types (ADTs). and when many people say "object oriented programming" they mean programming wth ADTs. This was what most of the C++ language popularity and evolution was about, thought its origins lie in simulation and in more of a messaging-based computation paradigm. I was using a version of C++ that supported that model with a task library as recently as 15 years ago, but don't know if such a package is still available. The current C++ standard neither supports nor prevents it.

OOP basics have been around much longer than video games have had any market footprint.

On Friday, July 18, 2025 at 07:47:36 PM GMT+2, Raoul Duke <rao...@gmail.com> wrote:

--

You received this message because you are subscribed to the Google Groups "object-composition" group.
To unsubscribe from this group and stop receiving emails from it, send an email to object-composit...@googlegroups.com.
To view this discussion visit

https://groups.google.com/d/msgid/object-composition/CAJ7XQb7EmR5gW9bcLEiuTXY7RwkhJM0twF0STmbiLZPkYNCsjg%40mail.gmail.com

.

[Hai Quang Kim]

this project is a debugger written in the optimized way.. interesting for anyone want to compare side by side thing like babyIDE

https://github.com/EpicGamesExt/raddebugger

On Tue, Aug 12, 2025, 6:25 PM Hai Quang Kim <wan...@gmail.com> wrote:

the game dev needs to optimize their code so they stick with memory aligned/cache friendly data structure... the author looks at the history and found the same technique was used in Sutherland's demo. He called it the lost art and blamed that people was focusing too much on compile time class structure. He blames that was a big mistake. He was sad that Alan Kay did not support memory aligned data structure because he thought it would not scale.
But yes, game dev's thinking is usually much more practical compared to OOP vision like an internet of objects which is never realized anyway :)

You received this message because you are subscribed to a topic in the Google Groups "object-composition" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/object-composition/dNcu1pSPYwc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to object-composit...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/object-composition/415833403.1463858.1754993877683%40mail.yahoo.com.

[Hai Quang Kim]

the game dev needs to optimize their code so they stick with memory aligned/cache friendly data structure... the author looks at the history and found the same technique was used in Sutherland's demo. He called it the lost art and blamed that people was focusing too much on compile time class structure. He blames that was a big mistake. He was sad that Alan Kay did not support memory aligned data structure because he thought it would not scale.
But yes, game dev's thinking is usually much more practical compared to OOP vision like an internet of objects which is never realized anyway :)

On Tue, Aug 12, 2025, 6:18 PM 'James O. Coplien' via object-composition <object-co...@googlegroups.com> wrote:

You received this message because you are subscribed to a topic in the Google Groups "object-composition" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/object-composition/dNcu1pSPYwc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to object-composit...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/object-composition/415833403.1463858.1754993877683%40mail.yahoo.com.

[Matthew Browne]

On 8/12/25 6:25 AM, Hai Quang Kim wrote:

But yes, game dev's thinking is usually much more practical compared to OOP vision like an internet of objects which is never realized anyway :)

It hasn't been realized in a widespread or mainstream way, but I think his vision is at least partly realized in the Croquet system. Thank you to Eze for mentioning Croquet in the previous thread—back in January I started looking into it, and very shortly after came across a Quora answer by Alan Kay talking about it as a project still active today that works toward aspects of his vision (he also mentioned Dynamicland). Unfortunately I can't find that link anymore. BTW, the latest iteration of Croquet has now been rebranded as Multisynq.

If you look up the most recent versions of Croquet/Multisynq, they're mainly marketed as a tool for AR (augmented reality) and real-time gaming, but that's not why I'm bringing it up. The underlying concept is much more significant and potentially broadly applicable, especially if it were further developed: distributed computation, with dynamic objects/services that can evolve over time while the system is running. Here are a couple of good links about it:

2003 paper from the older/original Croquet system written in Smalltalk (Kay himself was one of the people working on it):
https://tinlizzie.org/VPRIPapers/tr2003001_croq_collab.pdf

Interview with the creator of the more recent Croquet system with a web-based SDK written in Javascript:
https://voicesofvr.com/1088-croquets-browser-based-operating-system-for-the-metaverse-an-architectural-philosophical-deep-dive-into-real-time-collaboration/

This is so much better for collaborative systems than traditional approaches.

Here's something I've been wondering about...at what level of granularity is this more ambitious vision of "objects" most useful? As programmers with experience in programming languages with objects that exist on a single machine, most of us have become accustomed to thinking of objects in a fairly local way. But of course an entire web service can be thought of and interacted with as an "object", and that seems to me to be a level at which the concept of "messaging" becomes more powerful—a lot more than just a better or more flexible version of a method call.

That's not to say that these "objects" would need to be large and complex in every case...I could still imagine there being smaller objects like a "BankAccount" object, but instead of it being just some fields in memory + behavior, it would be a simplified interface to the whole mental object, with details like persistence and network synchronization taken care of behind the scenes. (I'm not naive enough to believe that the average professional programmer could avoid those details completely, but they at least would be taken care of at the system level and maintained through configuration rather than code most of the time.)

I'm not sure if the distributed computation concepts in Croquet were part of what Kay originally envisioned in the 70s (when imagining the future of computing), or if that came later, but it definitely gives more reason to pursue an "internet of objects" or at least a distributed network of objects.

[Hai Quang Kim]

I looked croquet few weeks ago. it was really interesting. I love to see it take off. It looks like the idea bebind croquet was part of distributed objects. Again, it was scaled down to game dev/VR/AR now. Game dev is always about simulation. So OOP is a natural fit until we hit the reality of perfomance.

--

You received this message because you are subscribed to a topic in the Google Groups "object-composition" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/object-composition/dNcu1pSPYwc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to object-composit...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/object-composition/f61851b0-de3f-4af0-a6d3-038c3a3c79b7%40gmail.com.

[James Coplien]

On 22 Aug 2025, at 11.24, Hai Quang Kim <wan...@gmail.com> wrote:

But yes, game dev's thinking is usually much more practical compared to OOP vision like an internet of objects which is never realized anyway :)

I’m not sure what is meant by “today’s thinking” or “practical” but my programs, and most of those of my clients, sure fit the network-of-objects model.

If you abandon this model, e.g. by doing TDD, you end up emulating top-down (or sometimes bottom-up) procedural design. Both have measurably worse coupling and cohesion metrics than when doing a more canonical OO. The research attests to this.

[Matthew Browne]

On 8/22/25 5:39 AM, James Coplien wrote:

If you abandon this model, e.g. by doing TDD, you end up emulating top-down (or sometimes bottom-up) procedural design. Both have measurably worse coupling and cohesion metrics than when doing a more canonical OO. The research attests to this.

Sort of related to this, here's another interesting paper:

https://www.cs.cmu.edu/~aldrich/papers/objects-essay.pdf

The author apparently missed Kay's grander vision for OO (or at least only discusses a more limited part of it), but it still has some very relevant insights for those interested in comparing programming paradigms. Among other things, the research for the paper looked at code sharing between different teams, especially how that applies to frameworks and libraries. The paper theorizes that OOP (it's mainly referring to class-based programming but it doesn't have to be limited to that) became widely used and has remained in wide use largely because of its superior ability to create "service abstractions" that are good for interoperability. A "service abstraction" could be something as simple as a base class or interface for a UI Component that can be used to create polymorphic UI components.

"The key design leverage provided by objects is the ability to define nontrivial abstractions that are modularly extensible, where instances of those extensions can interoperate in a first-class way."

It says that the key to this is dynamic dispatch. Obviously this is looking at things from a different angle than coupling and cohesion, but I suspect that good modularity that enables effective collaboration between different code authors/teams also means good coupling and cohesion metrics. 

BTW, the author's general research focus is on the usability (developer experience) of programming languages. Pretty interesting stuff.

(I am of course not claiming that OOP is always the best choice, I just wanted to bring up this real advantage it has that I think is often missed when comparing it with FP or procedural programming.)

[Raoul Duke]

all this makes me think:

i think defining "compose" would be a useful task in all such things; lots of connotations available from which to choose, or misunderstand each other. 

algebraic?

which algebra?

or more just rules of thumb?

iie: s there a real metric? could a static analysis provide the measure?

[Ezequiel Birman]

Thanks for the links! Jonathan Aldritch also started uploading a series of videos for his course Programming Language Pragmatics, looks interesting, and he also plays completely gratuitous fiddle interludes.

Re. FP and OOP: 1) Smalltalk and its derivatives are just as functional as Lisps. 2) Using CLOS won't make your program any less functional.

This subject of modelling and “the real world” has been talked about many times. Dan Ingalls and L Peter Deutsch often remind people of a rule they had at Parc: “You may cheat, but don't get caught”. Nobody can tell you how you have to design a system. There is no silver bullet. And there is no “one single reality” and “one single domain” to match. Systems and subsystems can be modeled and reified just as well as the perceived “main” domain. ECS is just another model that matches an aspect of the domain that we might be interested in capturing as knowledge in our design; and as designers, it should be our prerogative to exercise the freedom to choose it or ignore it. The same freedoms and responsibilities apply to the tools we use and more importantly, create. In What else is wrong with OOP (1992), Alan Knight writes:

OOP AND THE REAL WORLD
Choosing the right name for something is important. A name should be short, easy to remember, and clearly communicate the essential idea. Unfortunately, “object-oriented” fails in the last category.
 

The problem is that everyone knows what an object is. We intuitively “know” that object-oriented programming is all about objects: concrete, physical things that we can, with enough machinery, pick up and throw.

Processes can’t be objects. Relationships can’t be objects. Concepts can’t be objects. OOP is “good” because it writes programs that perfectly mimic the real world, and an OO program is “good” in direct proportion to its mimicry — like neural networks, which we all know work just like human brains. Being told that OOP is good for simulation and that it naturally models the problem domain only makes these misconceptions worse.

Smalltalk programmers tend to transcend these ideas more quickly than others because they’re confronted with examples of Schedulers, Controllers, Associations, and other non-concrete classes.
[...] 
THE REAL WORLD AGAIN

The idea of modeling the real world in detail is fallacious. In what we call “reality,” most things are human-imposed concepts. Reality consists mostly of interactions between elementary particles; the higher-level structures we perceive are abstractions useful in some specific domains. Reality can have very poor software engineering principles.

I encourage you to read the full article. 

So where do we drive abstractions? It's up to you! I think that Casey and I agree on this, and I find myself agreeing more with what he answered in the Q&A section than what he said during the talk section.

For its length, there are many relevant topics that are overlooked or misrepresented:

1. One could see Ross' Plex and dataless programming (see Kay and Ram email exchange) as a sort of proto-OOP; and Sketchpad is an OO program to the extent that it supports polymorphic operations over instances of masters. So, why no discussion of polymorphism?
2. It is hard to take criticism of Smalltalk seriously from a person who didn't spend some effort learning how to use it. Of course it has problems, and only a couple of them might be related to design-time (not compile-time) hierarchies.
3. C++ merges together classes and types. Why is he stating that as if it were a good thing? Java had to add interfaces to “solve” that.
4. No discussion of prototypes and delegation like in Self, nor the actor model, nor tuple spaces, nor hybrids like syndicated actors.
5. Inheritance, classical or not, is abused but also unjustly maligned; but why no mention of the shift towards composition over inheritance advocated by many, like the patterns community in the late eighties? Maybe even earlier.
6. There is a paragraph in The Early History of Smalltalk next to the one that Casey quotes, in which Kay speaks about Borning's Thinglab and Morphic (backported from Self), and the “pulling” strategy instead of “pushing”. Why not show those as examples of good design? Instead he shows only bad examples from random internet tutorials, and his own early experiments. Why?
7. Developing with teams, large or small: As far as I understand, the people at Parc were developing as a team with integrated source code version control and networked computers. Please correct me if I'm wrong.
8. No mention of the Dynabook project and its motivations except for some seconds in the Q&A; nor the STEPS project.
9. No explicit mention of DDD. Why?

-- 

Eze

--

You received this message because you are subscribed to the Google Groups "object-composition" group.

To unsubscribe from this group and stop receiving emails from it, send an email to object-composit...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/object-composition/fe01f901-44ea-4916-98b1-f32efe22c34a%40gmail.com.

[Matthew Browne]

Since Quang's initial post was about a month ago, in case I'm not the only one who needed a refresher... Casey Muratori is the speaker in the video in that initial post.

-Matt

To view this discussion visit https://groups.google.com/d/msgid/object-composition/CAOo%3Dt4fH0XVRCAwZ_RiQcZ_1RZ8Y3aNdKRZ-bag9sq-Bu5g1dA%40mail.gmail.com.

[Quang]

it means they started with procedural programming then moved to OOP class hierarchy, then to entity components, then to entity component system which is back to procedural programming and cpu cache friendly ..they don't see the link between mental model all the way from user thinking to the  code. I guess that is the key gap.