HN Books @HNBooksMonth

ECS and OOP are sides of the same coin, although apparently it is only visible to those that read SIGPLAN papers.

"Component Software: Beyond Object-Oriented Programming"

https://www.amazon.com/-/en/Clemens-Szyperski/dp/0201745720

One of the first publications on the matter.

⬐ dgb23

Not sure I get what you mean. As I see it, ECS has more of a relational character. Feels more like data pipeline than operations/messages on objects. I think the mental model matters the most here and that depends on how you think of objects. But then any attempt of defining OO objectively seems to be futile, there are conflicting historical and contemporary notions plus a whole bunch of jargon on top, depending on who you're asking.

As an example you could say that Scheme is more object oriented than Java or vice versa and there would be valid, typically cultural reasons for each.

In terms of ECS what kind of happens is that, yes, you have a model of an entity and can think of that as an object, but that is a projection of a set of components or a relation. You're not really talking to the entity as a whole all that much anymore. And it's not just "it satisfies this set of interfaces" either. Your systems literally define data transformations, each on a focused set of related components that matter to a system, which seems kind of the inverse of hiding data behind object interfaces.

⬐ pjmlp

That is when data oriented programming gets into the equation.

Classical ECS as it originally appeared on the literature is coding against interfaces, COM or Objective-C protocols style.

So yeah, one composes those interfaces together, there is no class inheritance, only composition, delegation, and a system is composed from a jungle of such components.

It is also a reason why DirectX is COM based, instead of basic Win32 calls.

⬐ ngrilly

What do you mean by classical ECS? I’ve always read that the Entity-Component-System approach originated in the gaming industry, completely unrelated to what you wrote about COM, etc.

⬐ pjmlp

Yes, the famous GDC talk.

Usually most stuff in game development tends to be rediscovered, as most people don't come from CS backgrounds.

⬐ bcrosby95

ECS is a departure of OOP in a component system.

I think some form of component programming is good for any flexible game. But ECS has some pretty specific prescriptions that makes it ECS, rather than some other component architecture.

I see a lot of hobby games that adopt the "EC" of "ECS", in the style of "ECS", but you're no longer ECS because you don't have the S.

Basically, they code like I did in C 25 years ago for my MUD.

⬐ glowcoil

> There has been an explosive growth in component software technologies since the first edition of this classic book was published. The advent of EJB, J2EE, CORBA 3, COM+ and the .NET framework are evidence of a maturing market in component software that goes 'beyond OOP'.

This book seems to be discussing distributed object systems, which is a sense of the word "component" that has little or nothing to do with the sense used by game developers in reference to the ECS architecture. Distributed object systems are designed to enable an object-oriented design philosophy to be used for a system which spans multiple address spaces or machines. The entity-component-system architecture is a methodology for organizing data layout and program functionality, usually within a single address space on a single machine, where the data associated with a given entity is spread across multiple components or subsystems and associated by index relations (much like a relational database), rather than being all grouped together in one place (as encouraged in OOP).

These two concepts (distributed object systems and ECS) are designed to solve different problems, they are generally used in different scenarios, and they apply at different levels of system organization. There is so little resemblance between the two that I have to conclude someone calling them "sides of the same coin" is either completely unfamiliar with one of them or is being deliberately misleading.

⬐ pjmlp

I also did not state that book was the canonical ECS model, rather that it was one of the first sources to move into discussing components instead of classes.

COM and DirectX aren't distributed object systems, nor Objective-C protocols, for example.

Don't confuse COM with DCOM and COM+.

Then there are the component models based on traits, mixins, patterns, message passing, type classes,... plenty of variants scattered around SIGPLAN and ECOOP papers.

⬐ Rusky

You are still conflating two totally unrelated things.

The book is one of the first sources to move into discussing "components," as in coding against interfaces/protocols/traits/etc.

ECS deals with "components," as in pieces of data composed using a relational model. This has nothing to do with interfaces or protocols whatsoever! It is practically the opposite thing- working directly with raw data, with no abstraction boundary.

You can't just pattern match on the word "component" and expect it to mean the same thing to everyone.

⬐ pjmlp

That is the next step, data oriented programming, which many confuse with ECS, as they tend to be used together.

⬐ Rusky

I am not talking about data oriented programming. With or without that sort of memory layout optimization, ECS "component" still refers to un-abstracted chunks of concrete data rather than interfaces/protocols/etc.

Let's step back even further and consider Unity's pre-DOTS "entities" and "components." These do not take the data oriented approach, are not typically even classified as ECS (e.g. because they lack the System aspect of that design). However, the components are clearly chunks of concrete data (transforms, meshes, rendering parameters, rigid bodies, etc.) rather than interfaces/protocols.

This is the sense in which ECS means "component." That book is not relevant to this sense.

⬐ pjmlp

A book that I clearly referred it was only one of the first ones that somehow started talking about this, I never stated it was the definition of ECS.

Apparently making the point about how relevant this specific book is, is what matters in this whole thread.

⬐ Rusky

It didn't start talking about "this." It started talking about something unrelated that you mistook for "this."

Algorithms and datastructures form the tactics of software development. your question is related to its strategy. Before you can master it, you first need to learn the concepts that are involved there. Don't buy books on methodologies, they are snake oil (I would love to be proven wrong by HN). The one book that stood out for me was this one:

Component Software: Beyond Object-Oriented Programming (Clemens Szyperski) https://www.amazon.com/Component-Software-Beyond-Object-Orie...

It's not a guide on how to do it, but it explains the ecosystem and forces in play (like why good components get rewritten, while bad ones persist). Once you understand these things you will have a better compass.

Published in 1997, "Component Software: Beyond Object-oriented Programming", followed by "Component-Based Software Engineering: Putting the Pieces Together" in 2001.

https://www.amazon.com/Component-Software-Beyond-Object-Orie...

https://www.amazon.com/Component-Based-Software-Engineering-...

The problem is how badly many schools teach OOP paradigms, and how many frameworks abuse a specific style of OOP.