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
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.
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.
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.
--
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.
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 :)
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.)
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.
--
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.
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.