Hacker News Reader

Comment by ferdowsi | Hacker News Reader

In all my experience with OOP, it's always been inheritance that is the root of all evil. Rust and Go got this correct by having class-like objects with no inheritance, to achieve encapsulation without fragility.

Unfortunately, all the other languages that included inheritance in their design can't wish it away. Devs are going to keep reaching for inheritance as the closest, most comfortable abstraction.

View on HN

>In all my experience with OOP, it's always been inheritance that is the root of all evil.

It's not, though, and the fact that people keep repeating this meme shows that most developers don't even bother thinking about issues they face beyond superficial blamesplaining.

The reason inheritance causes so many issues in languages like Java is because they are statically typed and also use classes as types[1]. Classes must be somewhere in the inheritance tree, hence you are forced into some place of that tree. To make things worse, Java has many keywords that restrict what inheritor of a class can do (private, final, etc).

Inheritance is much less troublesome in, say, Smalltalk, since the language is dynamically typed. If someone expects you to implement Foo, you can (almost always) just implement its relevant methods without explicitly extending the class. Thus, a whole host of annoying scenarios simply does not occur.

[1] BTW, this breaks one of the fundamental commandments of classic OOP: you should not depend on implementation details of an object, only on its message protocol. Obviously, it's impossible to be independent of implementation details if some library forces you to use a particular class.

You're describing interface-based polymorphism, which is what go and rust use. In go, I can have a struct with methods that implements a particular interface by implementing all the methods described in that interface, but I can't inhereit from another struct. The person you're replying to called this out as a better system too.

> Inheritance is much less troublesome in, say, Smalltalk, since the language is dynamically typed. If someone expects you to implement Foo, you can (almost always) just implement its relevant methods without explicitly extending the class.

Sorry, I don't understand this sentence. Isn't inheritance simply a way to avoid writing duplicate code? If you write the code to implement methods, isn't that not inheritance anymore?

Inheritance conflates code reuse ("avoid writing duplicate code") with polymorphism (allowing for multiple different instances to implement the same interface). It also allows for trampolining method calls up and down a hierarchy (a method in a base class might call another method which might be overridden by another class in the hierarchy).

Outside of OOP, we use composition for reuse and interfaces for polymorphism, and we don't trampoline method calls up and down a hierarchy because it's (probably?) always a bad idea. When we really need reuse and polymorphism, we can use both composition and interfaces, since the two are correctly orthogonal.

> Inheritance conflates code reuse ("avoid writing duplicate code") with polymorphism (allowing for multiple different instances to implement the same interface).

Note that languages like C++ allow for inheritance without polymorphism, i.e. pure implementation inheritance.

However, I also think that composition should be preferred whenever possible.

What the grandparent post means is that in dynamic languages you can just implement one of the "base" methods yourself instead of inheriting from a class that's bigger than you need, in order to avoid problems. I personally don't have an opinion on that, but it's not something I'd do myself.

Also, like the sibling said, inheritance is a tool that does multiple things: code reuse, which we call implementation inheritance, being the one everyone hates (the age-old advice is to use composition for code reuse instead), and interface inheritance being the one everyone loves.

> It's not, though, and the fact that people keep repeating this meme shows that most developers don't even bother thinking about issues they face beyond superficial blamesplaining.

I don't know that I'd say "inheritance is the root of all evil" (there are lots of antipatterns in OOP that are unrelated to inheritance, like Joe Armstrong's banana-gorilla-jungle observation) but I will say that inheritance is pretty close to useless in the best case and harmful in most cases. And I say this as someone who learned to program and then became a professional programmer when OOP was all the rage. I was taught OOP without the previous bias of other paradigms; it was only after learning other paradigms that I was able to articulate frustrations I was having with OOP. The implication that people who criticize inheritance in this way "haven't bothered to think" is patently false in the best case, and laughably arrogant in the worst case.

> The reason inheritance causes so many issues in languages like Java is because they are statically typed and also use classes as types[1]. Classes must be somewhere in the inheritance tree, hence you are forced into some place of that tree. To make things worse, Java has many keywords that restrict what inheritor of a class can do (private, final, etc).

Fear not, Python is dynamically typed and inheritance is a mess there as well.

> If someone expects you to implement Foo, you can (almost always) just implement its relevant methods without explicitly extending the class.

This is just structural subtyping (see Go's interfaces for a statically typed example of structural subtyping) also known as "duck typing". It seems like you're positing that the problems with inheritance derive from nominal subtyping (e.g., Java's `implements` keyword), but these things are orthogonal. Python has duck typing ("structural subtyping") and its inheritance is no less painful than Java's. Similarly, Rust has nominal subtyping (a type must explicitly implement a trait) and it has none of the inheritance-related problems that Python and Java have.

I feel like OOP always had the nerd catnip problem. Since the very beginning the various programming tutorials would have the contrived examples of animals and canines and dogs, or geometric shapes and triangles etc. which just managed to ring a particular very satisfying bell in people's heads. It was just such a neat concept with those examples that just made sense. How it turned out in practice is a different story but I feel this had a lot to do with the enthusiastic uptake.

1983 Smlltalk-80: The Language and Its Implementation by Adele Goldberg and David Robson had pretty good example with none of this animal/mammal/dog crap. Not sure when the trend for giving awful examples like this really started, but I don't think it was "from the very beginning".

To me there are about three tiers of this basic insight:

1. Inheritance causes all kinds of issues so you shouldn’t use it.

2. Actually, inheritance is fine as long as you do it right (e.g. Liskov)

3. Actually, getting part 2 right is difficult, and the heavy risks of getting it wrong aren’t worth the minor benefits of inheritance.

Polymorphism is good. You describe polymorphism.

Inheritance is bad. Inheritance is patching a class and overriding some of its methods, while leaving others intact. This brings all kinds of unexpected interplay between methods of different levels of overriding. A typical example is http://www.cse.psu.edu/~deh25/cmpsc473/jokes00/joke01.html

Ideally all "concrete classes" with method implementations should be final, and the polymorphism should be achieved via interfaces / typeclasses / traits, or purely abstract classes where these are not available. Reuse of implementation should be achieved via composition; there are several ergonomic ways to express it.

> Simulator supervisors report that pilots from that point onward have strictly avoided kangaroos, just as they were meant to.

Won't fix; working as intended.

> Polymorphism is good. You describe polymorphism.

It also seems like they're describing the nominal typing of Java versus a structural approach.

Haskell and, IIRC, Rust allow you to declare that a certain data type conforms to some interface, and describe how, by listing / adding the functions with necessary signatures.

This allows to have the upsides of structural polymorphism without losing static checks.

Go, OTOH, goes all the way structural.

> Haskell and, IIRC, Rust allow you to declare that a certain data type conforms to some interface ...

I believe at least in the case of Haskell, you are referring to type classes[0].

0 - https://wiki.haskell.org/OOP_vs_type_classes

I'm unfamiliar with anything like that in Rust, beyond Rust's structural approach to tuples. I'd love to hear more about it, though!

I think they're just talking about how you have to declare what trait a function implementation is for, rather than having it derived from the type signature alone. The `impl Trait`[0] syntax. In Go, you don't need to declare that the function implementations are being implemented for a particular interface, you just have to match the type signatures and function names.

Rust's way can help avoid some errors. You can't accidentally implement an interface, whereas in Go you can if you happen to implement a group of functions with appropriate names and type signatures. It's unlikely to cause actual bugs (you'd have to misuse the resulting implementation) but can be conceptually somewhat confusing.

[0] https://doc.rust-lang.org/book/ch10-02-traits.html#returning...

> In all my experience with OOP, it's always been inheritance that is the root of all evil.

I have this "theory" in the back of my head that trees are usually the wrong things to model thing in life but it's what come to us naturally. For example, a blog with categories and sub-catogories for articles (a tree, inheritence) can often describe the content better by using tags (a graph, composition). I think that's because trees are easy to deal with and understand, but graphs are more "open" with what you can do.

Except that trees are by definition graphs with specific conditions on direction and cycles.

Perhaps it is those very conditions which make trees less useful than they at first appear.

I would argue that its those restrictions that make trees a useful simplification, but also a simplification

In general yes, but in certain case they force you to simplify in a way that's later painful.

A tree is a graph where all vertices have exactly one path through them.

Trees are often implemented using composition, and inheritance can be graphical (the Diamond Problem is not game over).

    A
   / \
  B   C
 / \ / \
 D E F G

This is clearly a tree, but doesn't B have 2 paths through it? A->B->D and A->B->E.

You're right. The correct definition is that any two vertices are connected by (i.e. are the endpoints of) exactly one path.

Fun fact -- since graph-theory trees are undirected by definition, an inheritance graph is more properly called an arborescence (for single inheritance). For multiple inheritance it's a DAG (with diamond-pattern) or a directed tree (without).

> any two vertices are connected by (i.e. are the endpoints of) exactly one path

No.

You just described a connected acyclic graph, not a tree.

In addition to being connected and acyclic, a tree must also have a root, and is thus implicitly directed.

Data modelling in OOP is an exercise in coming up with Platonic ideals, resulting in a hierarchical (tree-like) ontology as you try to choose of the atributes as the categorisation dimension, and leaving everything else as properties.

    class Animal
    class Mammal inherits Animal
    class Feline inherits Mammal
    class Cat inherits Feline
    ...

This is different than just asserting facts with data, which can lie in multiple dimensions.

    Is Feline
    Is Mammal
    Is Fluffy
    Is White
    Does Meow

The later is a much more flexible data model as it more closely mimics observed (subjective) reality, and is less disturbed when a new (counter-)example is introduced, but is also harder to reason about than idealised categories.

Hence traits?

And ECS is fundamentally a trait system!

I know all the terms are overloaded nowadays so everything’s kinda unclear but I always wished that ECS components had been called traits, because adding a component to an entity gives it some a trait like “this thing has a position in the world” or “this thing can be drawn” (and perhaps have systems named “behaviors”, because systems add behavior to entities based on the traits/components that they have)

Years ago, when ECS was just starting to be talked about (after Adam Matrins blog posts), I wrote a toy ECS where I used that naming convention. Nowadays I stick to the mainstream terminology since that’s what other people know.

Yeah I've commented before that "entity component system" is roughly synonymous with "thing piece thing" or something like that - it's a really bad name because it's so ambiguous. Anything including the term trait would be 1000x better because at least "trait" means something.

I think it's named ECS because before then entity+component designs were common in games. ECS generally took the behavior off the C and puts it in the S.

They have, but there is a certain tendency to ignore CS literature.

"Component Software: Beyond Object-Oriented Programming"

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

1st edition, 1998

To your point, there are programs that deal in ontologies. These are the only times that it makes sense to care about the relationship between things. For example, an ontology might have a concept of a city and it might know that Munich is a city. But this is all data, it isn't about "types". It never makes sense to write `class Munich extends City {}` for the purpose of your program. Rather, you might have:

    struct Entity {
        name: string,
        parent: Option<Entity>,
    }

    let city = Entity { name: "city", parent: None };
    let munich = Entity { name: "Munich", parent: Some(city) };

That said, if you really wanted to make life hard for yourself, you could use types as data provided your language has a runtime type system and reflection (you could dynamically generate `class City` and `class Munich extends City` when deserializing `[{name: "city", parent: null}, {name: "Munich", parent: "city"}]` or something). But this is the kind of Rube-Goldberg territory that "Kingdom of Nouns" thinking leads us toward.

Uh, no. Either of those are possible without leaving the OO paradigm, and only very poorly taught and inexperienced students model data as an object inheritance hierarchy.

If only.

Spoken like someone who has never seen any kind of representative sample subset of real world code...

No, the problem is that code by poorly taught and inexperienced developers is rife. Heck it’s on display throughout the threads on this topic; for maximum irony, often as an example of “why <concept> is bad”, the author not realising this merely telegraphs their own limitations.

> Data modelling in OOP is an exercise in coming up with Platonic ideals, resulting in a hierarchical (tree-like) ontology as you try to choose of the atributes as the categorisation dimension, and leaving everything else as properties.

Only if that is how you choose to model the problem domain.

> This is different than just asserting facts with data, which can lie in multiple dimensions.

The "Is ..." examples you detail can just as easily be modeled "in OOP" as:

  class Animal {
    private knownFacts = ...

    def is (fact) ...
  }

Without the need for "a hierarchical (tree-like) ontology", since obviously this would be a poor choice in this situation.

Not the same thing, as the facts are now a property of Animal. My second example doesn't even mention Animal. You still have the problem of "putting things into a category" vs. just asserting facts.

There is an implicit subject you are asserting facts about though. You clearly are talking about a fluffy, white Cat in your example. It’s essentially structural rather than nominal typing. The “fluffy, white Cat” is defined by its traits. We could define a type Cat which has a subset of those traits and then be able to use our “fluffy, white Cat” anywhere we can use a Cat. We only name them to avoid having to name all the traits all the time. Doesn’t make it any less object based.

Structural typing is really cool though. An object built from a named, saved recipe will work just as well as something cobbled together on the fly and at runtime you won’t even know which is which. It’s the basis of a lot of general purpose game engines composition based game object interface.

I’ve also found it extremely fun to use with TypeScript.

> There is an implicit subject you are asserting facts about though. You clearly are talking about a fluffy, white Cat in your example.

No, I'm not, because I didn't assert this fact (it's a Cat).

See how hard it is to break free from this mindset of objects.

Right as I said it’s structural typing. It’s implicit that the traits are grouped together to describe something. And individual traits could be grouped together with completely different ones to describe something else. That you choose not to name it doesn’t change that the trait collection applies to fluffy, white Cats whether you like that or not. I can even choose to call it one thing and you can choose to call it something else and the types will remain interchangeable. You can even leave your type anonymous and it will still be interchangeable.

If f(x) is implemented for white xs and separately for fluffy xs, how do you disambiguate f(x) for x that's both white and fluffy?

Humans have a natural tendency to refine a single idea by splitting it into two based on a differentiating factor. This ends up looking like a tree when applied repeatedly. Dichotomous keys for species identification are another example of this.

The problem being that they don't categorize things into one tree, but many. One can view the same thing in different ways. OOP tree hierarchies do not allow that.

It's like trying to categorize your photos in a directory tree. Do you categorize by year first, by person, or location? There is no correct answer. What people want instead is a photo album with tags. The same problem applies to OOP.

> What people want instead is a photo album with tags

What you really want is hierarchal tags :)

No, no. We want tags. Later we want hierarchal tags (with some complex workarounds to maintain some legacy thing included in the implementation).

> It's like trying to categorize your photos in a directory tree

A problem that made me think about tags instead of categories was precisely that: I have photos that I want to organize. I started by organizing them by person with a folder for each person. But how do I handle a photo where multiple people are in it? Tags don't have this problem. Unfortunately file systems don't support tags.

  Silly monkeys
  Give them thumbs, they forge a blade
  And where there's one they're bound to divide it
  Right in two

SCNR :)

For everyone that doesn't know the text: I recommend listening to Tool's "Right in two". Although the text originally talks about war and strive, not programming. ;)

> I have this "theory" in the back of my head that trees are usually the wrong things to model thing in life but it's what come to us naturally.

Have you by any chance read the relevant passages in SICP? It has some things to say about OOP ontologies.

Could you link this?

https://mitpress.mit.edu/sites/default/files/sicp/full-text/...

Possibly that section. It's not about OOP specifically, but about type hierarchies generally.

I don't think I did, I didn't finish the first chapter of SICP. I'm sure that I'm not the first one to come up with this though.

There's a great old (2005) blog post on this topic:

Clay Shirky - Ontology is Overrated: Categories, Links, and Tags

https://web.archive.org/web/20191117162526/http://shirky.com...

Folks may enjoy some of these old posts too.

https://en.m.wikipedia.org/wiki/Pyrrhonism

For example, putting regions under a cold climates category, might not make sense to someone living near the pole where they would consider the same regions to be warm climates.

Thanks, that was a great read. Tangentially related, but I wonder what's the impact of Windows having a really bad search. Maybe people are thus relying more on the folder hierarchies, and that influences how they think?

You might enjoy this essay from 1965, "A City is Not a Tree": https://www.patternlanguage.com/archive/cityisnotatree.html

Oh man, I have a rabbit hole for you.

https://en.wikipedia.org/wiki/Rhizome_(philosophy)

Here's a near-decade old talk from me on this exact topic: https://www.youtube.com/watch?v=YfKAScYkGlk

I haven't watched this in like... a long time, so maybe I'd think it's bad now.

I recommend Manuel de Landa (stylizes his name to Delanda these days), particularly “Intensive Science and Virtual Philosophy” if your flavor is Anglo style analytical philosophy.

The relevant Deleuze texts (A Thousand Plateaus) can be infuriating if you’re not open to this whole other style of thinking, but Deleuze is no postmodern, he’s a realist and a materialist and sort of a science worshipper, albeit from an angle that would make Neil deGrasse Tyson start bleeding from his nose until he passed out, if he ever grokked it. Start with Delanda, probably.

[googling a little, this isn’t great but isn’t bad for something readily accessible: http://dar.aucegypt.edu/bitstream/handle/10526/3534/DeLanda%... ]

Heck yeah, in full agreement with all of that.

I've previously suggested that initiation is the "root of all evil." See my essay:

Object Oriented Programming Is An Expensive Disaster Which Must End:

http://www.smashcompany.com/technology/object-oriented-progr...

Funny to see the author of one of my favourite blog posts on the internet get downvoted.

Thank you. I believe some people downvote it based on the title, rather than the argument, but I believe the title is also accurate.

The weirdest thing is that the ECS as a way of building a game is inherently object oriented. You take a set of components and compose an object called an entity. The components on the entity define not only it's data but also it's behavior by the set of systems that act on the corresponding components. And you can take these object definitions and inherit them to add additional behavior or change the existing behavior by adding more components to the new definition.

Then if you solve the entity communication conundrum with message passing and don't allow entities to directly access one another's data you basically have all the elements.

ECS is really just OOP with dynamic multiple inheritance: an object can inherit from multiple base "classes" (with "components" providing the data and "systems" providing the code) and this inheritance structure can be changed at runtime, by adding/removing components. Everything else (struct-of-arrays vs. array-of-structs) is just low-level implementation details.

When I implemented a variation on ECS for a game I'm building, I did exactly as you suggest, re, message passing: components receive and respond to messages but their implementation is hidden.

Inheritance is one way of describing it but I don't think the term really fits. An object is composed of multiple components, and the composition can be changed at runtime. Saying that the object inherits from multiple base "classes" seems like it just makes the concept less clear.

Some languages have class-based systems with inheritance: one class inherits from another, and methods implemented in the superclass can be used in the subclass. Some languages have prototype-based systems with inheritance: one object inherits from another, and methods implemented in the prototype can be used in the object.

Component-based systems don't really fit my mental model of inheritance here.

> ECS is really just OOP with dynamic multiple inheritance

It's composition, not inheritance.

Technically, it's neither. Unless your programming language directly supports ECS, you're not going to be implementing the relationship between entities and components as either proper inheritance or a collection of data members, because neither of those can be changed dynamically.

No, "technically" and in all other regards, it's composition, plain and simple.

There's nothing special about composition that it requires language support, or that it has to be static for it to be considered composition. You can implement dynamic composition in OOP simply by having a List of components, and that's how many games that don't use ECS did and still do. Composition has absolutely nothing to do with inheritance or with requiring static data members.

Unlike you're claiming, the relationship between entities and components definitely does exist in ECS, just not in an OOP way, because ECS is not OOP (even though ECS can be implemented in any language).

> The components on the entity define not only it's data but also it's behavior by the set of systems that act on the corresponding components. And you can take these object definitions and inherit them to add additional behavior or change the existing behavior by adding more components to the new definition.

This seems to miss what ECS actually is, unless you're just referring to the old-school way of doing entity components and not the data-oriented way.

Data-oriented ECS way of doing things is to separate state and behaviour. Entity components essentially become structs where their only behaviour is potentially some getter/setter utilities.

Behaviours are then state-less systems (just functions, essentially) which act on a set of components.

For example, a PhysicsUpdateBehaviour might take in a RigidBodyComponent and a HealthComponent to perform a physics update and apply physics/fall based damage.

The main benefit of ECS (imo) isn't even really performance. It makes code in complicated game projects much easier to manage by clarifying the game loop and by making it much more obvious how and when entity state is being modified.

It's the kind of thing that potentially complicates a smaller project, but makes larger more complex projects easier to manage.

This Overwatch GDC talk is the best breakdown/example of data-oriented ECS in a AAA game that I know of: https://www.youtube.com/watch?v=W3aieHjyNvw

I know what an ECS is. Components are decoupled from systems (not not visa versa) but the actual behavior of an entity is defined by the set of systems that run on the set of components so in that sense the set of components defined what the Entity is including it's behavior. An Entity is defined in terms of it's data and it's data brings along behavior.

> You take a set of components and compose an object called an entity.

That’s an overly broad definition of “object”, since under that same definition a record type (C struct) or any other blob of memory is an object.

In the common type of “components only store data” ECS, the entity is an ID (think a foreign key) that connects multiple records together and systems are independent functions (they are not tied to nor live in an entity) that operate on collections of subsets of these components.

That sounds a lot more like old school C-like procedural programming to me than it does like OOP. There’s more to OOP than the data attributes a class contains (eg the associated methods)

I suppose it depends on your game engine and your ECS, but since entities don’t contain logic, it’s the systems that communicate between each other (either by sending messages or by accessing the other entities components or by just calling functions of other systems). This isn’t all that different from different parts of a procedural program communicating. Although I do personally think that making a system be an OOP object does makes sense, but it doesn’t have to be.

With that said, it seems pretty common in games to use a component system that isn’t “pure ECS” (like the default Unity components prior to their new ECS), which definitely seems like typical OOP to me, just decomposed a bit more.

> That’s an overly broad definition of “object”, since under that same definition a record type (C struct) or any other blob of memory is an object.

I think that's because you seem to have stopped at the second sentence the rest is important as well. I'm also talking about a level above the ECS implementation. What is the running thing actually doing.

> With that said, it seems pretty common in games to use a component system that isn’t “pure ECS” (like the default Unity components prior to their new ECS), which definitely seems like typical OOP to me, just decomposed a bit more.

Yes this also models much the same thing at runtime.

How is the running thing operating on components any different from functions in a purely procedural language like C operating on records/structs?

> Yes this also models much the same thing at runtime.

In a different way, though. It also generally misses out on the data-oriented benefits of an ECS.

It's the conceptual organization. The Entity is defined by data (components) that bring along behavior (systems). So an entity executing at runtime (say you're making Pacman and it's the Red Ghost) is an object and is defined by the combination of data and behavior.

The underlying implementation is irrelevant basically. You could implement the ECS in an OOP style and the same it true. You could do it in a functional style and it would be true. You could do it in straight bytecode for some obscure hobby VM and it would be true.

Unlike traditional OOP, the data and behavior are decoupled though. Similar to data and functions.

That is, you can add components that don’t get operated on by any particular systems because the entity doesn’t have the other prerequisite components and you can have systems that don’t operate on the components. You can have many systems operate on one particular component and many components operated on by a system.

In OOP, the data and the operations are packaged to whether as one. You also typically have encapsulation and it’s considered bad practice for one class to operate on another classes data directly.

It seems that both models achieve similar things, but they’re far from the same thing. Just like how procedural or functional programming achieve similar things to OOP, and you can do OOP in these paradigms or these paradigms in OOP. There’s a lot of cross over, but that doesn’t make them all the same thing.

If anything, I’d say that ECS are a relational model but with a very limited query system compared to something like SQL.

> Unlike traditional OOP, the data and behavior are decoupled though. Similar to data and functions.

Except the data and behavior aren't decoupled. The components are decoupled from the systems, but the systems are still very much dependent on the components. Just like a method is usually dependent on the instances data or a function is dependent on the data passed in.

> That is, you can add components that don’t get operated on by any particular systems because the entity doesn’t have the other prerequisite components and you can have systems that don’t operate on the components. You can have many systems operate on one particular component and many components operated on by a system.

You can have a member that isn't operated on by any methods and methods that don't operate on members.

At the level your talking about there isn't much difference between a function and a method. It's mostly syntax.

method(instancedata);

verses

instancedata.method();

Really we're getting caught up in implementation details because a class definition isn't the be all of how to define an object. There is really no reason we couldn't define objects in a programming language through composition.

ECS very much is a relational model and you're right it's very limited in comparison to things like SQL because it's trying to model something very simple. Game Objects! The relations defined are exactly what brings data and behavior together under to create the runtime object we call an Entity under the pattern conventions.

> Just like a method is usually dependent on the instances data or a function is dependent on the data passed in.

Just like a C function operating on a C struct. So, what, in your opinion, is the difference between procedural programming and OOP?

> It's mostly syntax.

Which is why I think there is more to OOP than a classes attributes and it’s methods. There is also inheritance, encapsulation levels, the fact that an objects identity is its attributes (the object is its data, an entity has its components but is separate from them), the fact that an object is a singular thing which it’s methods operate on (as opposed to how systems operate on collections of components, imagine a class system where a method operated on all instances of that class!).

Sure at the end of the day it’s all the same and we’re just arguing semantics, but that was my point and what I lead with: it’s an overly broad definition. If definitions are too broad then they really don’t add any value, but I believe a distinction between OOP and ECS is useful because they are used in different ways.

But fundamentally I don’t disagree, I even once wrote a blog post about how all of the OOP principles exist in an ECS! I just don’t believe that thinking of them as slightly different implantations of OOP is useful because of how their properties differ.

I actually wrote way back at the start about encapsulation and inheritance (along with message passing). So I'm not sure my definition really is overly broad.

I'm also mostly talking about the runtime consequences of the things that most people worry about at the time of programming.

But thanks for making me defend my thought!

Sure ECS is object oriented in the same way C99 is. Yeah, technically you are building up some OOP functionality, the same way you emulate constructors and instance methods in C by making functions to init data structures and functions that take references to a struct to modify it's data. That doesn't make C object oriented.

In ECS you are decoupling data from behavior, which is basically the entire paradigm of languages like rust and go. You could argue that by defining systems in a way that they run on certain components you are defining behavior and data in one, but I think that's a stretch.

It clearly differs from OOP when I have 2 entities with components that have overlapping and non-overlapping systems. If e1 has components c1 and c2, and e2 has components c2 and c3, and c1 and c2 are used in system s1 while c2 and c3 are used in system s2, I don't see how you would model that with OOP without adding data to classes that don't need it. In OOP both e1 and e2 would need all the logic from s1 and s2, or needlessly specialized versions of s1 and s2. Which would be solved via inheritance (either class based or interface based).

In ECS your data exists in an array of components and any part of your program can operate on any component however it wants. I've never needed message passing for anything I've worked on.

That's not to mention that the main benefits of ECS have nothing to do with language paradigm. ECS main advantage is cache coherency and easier parallelism.

You're too worried about the underlying implementation. Think a bit more about the runtime expression in terms of the resulting Entities and how the set of components linked to them defines data and behavior and what you could do conceptually to extend that.

> That's not to mention that the main benefits of ECS have nothing to do with language paradigm. ECS main advantage is cache coherency and easier parallelism.

ECS is not data-oriented by default. :)

I have a long post explaining things in this thread here: https://news.ycombinator.com/item?id=27663218

My comment has nothing to do with implementation. We're talking about ECS in the context of DoD so I'm not sure what relevance being data-oriented by default has. It seems like you're just confusing the concepts of ECS, DoD, and composition.

Your entire post on ECS is, "If you don't use DoD with ECS than you're not using DoD". Well yeah.. obviously? If you implement an ECS and then use it without data-oriented structures, then yes obviously you don't have data-oriented design.

You're creating a strawman. You're saying if you take ECS, remove the idea of storing components independently of entities, and pass them in an inefficient manner to systems, then you don't have DoD. ECS isn't inherently DoD, literally nothing is. Arrays aren't inherently cache friendly. There's nothing stopping you from making a language that allocates data randomly throughout reserved memory and every array element points to each location. No one is arguing ECS is inherently DoD, but it is a good design to facilitate DoD.

> For example we might want to do damage to another entity entirely.

Add a damaged component to the entity to damage. Consume damage component in a system.

> Or we might want to look up the properties of the piece of ground we're stood on

Use a position component on the entity standing on the ground. Consume the position in a system and look at the properties of the terrain map at that position. Even simpler for grid based maps.

> We're also ignoring interacting with other components or the world and how that might work

You interact with other components by defining interactions in systems based on those components.

You've created an ECS in a way that doesn't take advantage of any of the benefits, and complaining that all you're left with is the disadvantages.

The approach I talk about with archetypes is the one used by Unity and many open source ECS implementations. It’s a pretty standard way to solve the issue.

ECS (which I have not used) sounds a lot like Traits. The name and core concepts for Traits were defined in 2003 in an ECOOP paper [1]. I think traits were first implemented by Squeak Smalltalk in 2005.

[1] http://scg.unibe.ch/archive/papers/Scha03aTraits.pdf

Very similar although in an ECS the relationship is backwards, Entities get behaviour based on what data they contain rather than getting behaviour from traits and needing to add state to make them work.

The ECS approach can lead to some confusing things like adding a component to an Entity and having strange behaviour result as a system the programmer didn’t expect to be triggered is run. This can lead to systems having quite complex definitions based not just on the components the system needs to run but also on the components that shouldn’t be present and so on.

From a distant point of view, everything is OOP. You can treat anything like a black box that you push button on to make things. You push things on your keyboard, without knowing how it works. Your keyboards activate things on your computer, without knowing how it works. The computer ask the screen to update with the new date, without knowing how it works.

From a distant point of view, everything is data oriented. Your thought are transformed into keyboards presses by the keyboards, that are transformed into events by your computer, that is transformed into what you see by your screen.

I could do the same with a frozen pizza factory: you can see the ingredients flow in the machines (functions), or you can see the different machines passing things to others like objects. The problem is that then the classification between "OOP" and "non-OOP" doesn't mean anything anymore and is now useless.

This isn’t a distant point of view though. I make games every day professionally and think a lot about how to make making them more accessible. Both are part of my job. People building them shouldn’t just consider how an ECS looks under the hood but how it works for someone using it which is as a system for building runtime objects. Particularly if you look a little deeper than the popular Internet view of the basics to what an actual usable implementation looks like.

Like anything, inheritance can be used poorly, just as anyone can right poorly encapsulated code in Rust or Go. You might be able to convince me that inheritance is too dangerous for idiots, but then so is a computer, and we'd be debating where to draw the line of how smart/experienced you have to be to use it safely.

This article from Noel, and the ones from Mike he links to, get under the hood and into "what is the compiler doing" and "what is the CPU doing". Down here, we're looking at how to use the features of whatever language we're using to get the results we want, rather than "how should i program oop gud".

It's the dose that makes the poison. Of course we want nice typed collection libraries and interfaces. The kids go overboard though.

Go actually does implement inheritance, albeit in a roundabout sort of way: a struct can have one or more base members, and any method defined on the base members is accessible from the new struct implicitly, so they also implicitly implement any interface that was implemented by their base members.

Here's an example (in the playground, because it gets a bit long): https://play.golang.org/p/TblQypAbIL2

That's not inheritance, it's just syntax sugar that lets a struct delegate method calls to one of its members. In other words:

    struct Foo {}

    func (f *Foo) baz() { println("Foo.baz()") }
    func (f *Foo) qux() { f.baz() }

Given the above, `struct Bar { Foo }` is the same as:

    struct Bar { Foo Foo } // field called `Foo` of type `Foo`

    func (b Bar) baz() { b.Foo.baz() }
    func (b Bar) qux() { b.Foo.qux() }

Since it's just syntax sugar and not inheritance, we can't put a `Bar` in a list of `Foo`s nor can we pass a `Bar` into a function that expects a `Foo`. It also means that if Bar overrides its `baz()` method like so:

    func (b Bar) baz() { println("Bar.baz()") }

that calling `Bar.qux()` will still print "Foo.baz" and not "Bar.baz" (most languages with inheritance will print "Bar.baz", which is to say methods are virtual by default).

Using interfaces, you easily get polymorphism as well:

  type FooI interface{ baz(); qux(); }
  foos := []FooI{&Foo{}, &Bar{}}

Regarding overriding, you're right that it doesn't work out of the box. However, you can make "extensible classes" with just a little boilerplate:

  type Foo struct {FooI this}
  func (f *Foo) baz() { println("Foo.baz()") }
  func (f *Foo) qux() { f.this.baz() }
  func NewFoo() Foo { f := Foo{}; f.this = &f; return f }

Now, to extend Foo:

  type Bar struct {Foo}
  func (b *Bar) baz() { println("Bar.baz()") } //the override
  func NewBar() Bar { b := Bar{}; b.Foo.this = &b; return b } //this would work even if we didn't override baz

  func main() {
    foo := NewFoo()
    bar := NewBar()
    foos := []FooI{&foo, &bar}
    for _,f := range foos {
      f.qux()
    } //prints Foo.baz(), then Bar.baz()
  }

Since best practice even in C++ or C# or Java is to only allow inheritance for classes that are designed with it in mind, and since Go anyway has lots of other boilerplate, this shouldn't be unbearable if required.

Playground link for anyone curious: https://play.golang.org/p/SKGhANuBGgB

yeah, you absolutely can emulate this stuff to a large degree. My point wasn't that it's impossible, but rather you have to build it from orthogonal primitives. And even then I don't think you can get the same degree of trampolining that you can get with inheritance (for example, we can get Bar.qux() to call Foo.baz() easily enough via interfaces, but then IIRC it's trickier to get Foo.baz() to call Bar.asdf()--that said I'm too busy to think it through properly).

I think that it can work. IMO ActiveRecord is a perfect use of inheritance. You get tons of useful functionality out of the box, you don't have to worry about what that code looks like, and it's easy to extend or modify it. But often when I see co-workers come up with their own hierarchies, it saves maybe a couple of lines of code and makes it 5x more difficult to read, since you're jumping between parent and child classes and trying to keep track of the order of execution.

I don't agree with this, and I'm personally an anti-OOP militant.

Inheritance isn't the root of all evil, dynamic dispatch is. It's a remarkably powerful implementation detail but one with enormous cost, regardless of whether you're using an AoT/JIT compiled or interpreted language.

What enormous cost — slightly slower function calls? That's a pretty minor cost, and dynamic dispatch can be extremely useful sometimes.

Enormously slower function calls and zero inlining without advanced dynamic compilation, which has a number of pitfalls.

Devirtualization optimizations can turn semantically "dynamic" dispatches into static dispatches, but sometimes you really just need a dynamic dispatch. Note that a dynamic dispatch doesn't have to be anything more than a branch. Further, sometimes devirtualizing everything leads to enormous binaries and compile times. Runtime performance isn't everything, and it's typically better to opt-into devirtualization rather than to opt-out of it.

You must have absurd standards if you find dynamic dispatch to be unacceptably slow. Also, yeah, not every function call needs to be inlined. One level of indirection on top of jumping into a new function isn't really much overhead at all, unless you're doing it for literally every function call.

As opposed to passing function pointers everywhere, callback hell and friends? Or which language does it well in your opinion? The fact is, dynamic dispatch is needed, because not everything can be known at compile time. And as in a recent thread a HNer rightly noted (could not find it where I read it), the actually expensive thing in programming is flexibility.

Disagree. Go and Rust both have dynamic dispatch and neither have the problems that inheritance has. Even in C which lacks dynamic dispatch, people will either try to build it at the expense of type safety or they will try to manage an impossibly complex implicit state machine (I've seen this in a lot of critical real time systems).

I would wager that in most ordinary C programs it is worse. You can’t even reason about code anymore with all the callbacks.

> Inheritance isn't the root of all evil, dynamic dispatch is. It's a remarkably powerful implementation detail but one with enormous cost ...

Dynamic dispatching typically costs one pointer lookup in a vtable[0]. By "typically", I specifically mean "in any production quality run-time environment." This is not an "enormous cost" by any reasonable definition.

0 - https://en.wikipedia.org/wiki/Virtual_method_table

Reply on news.ycombinator.com