Hacker News Reader

I think you'd benefit from taking a look at Entity Component Systems. Generally used for games, this programming pattern assigns behaviour to entities based on the components that they have. Moreover, neither entities nor components on their own actually own any behaviour. Behaviour occurs by systems that operate on entities with the associated component "signature".

For example, an entity with a position and a velocity component (position could hold x,y,z values and velocity vx,vy,vz values) could be operated on by a movementSystem (which adds behaviour to any entities that have both a position and velocity component, and updates position values based on velocity values.)

The nice thing about such a system is that the taxonomy as you call it gets defined when you instantiate the systems of your program. If you have entities with position and velocity components but dont want to use a movementsystem to operate on them, you simply dont instantiate the movementsystem. Pretty flexible, but not used excessively outside of video games.

Thank you - I think this was probably the inspiration or seed for what I was thinking :)

I was amazed when I saw the ECS architecture when I filled my toe into game development.

I remember wanting to apply it to other areas outside of game development.

It's interesting though that a paradigm that intends to help simulate the real world has been eschewed for speed and maintainability in favour of something like ECS in game development, which is all about simulation.

Yeah it's an interesting pattern and even when implemented in an OOP language ignores most OOP ideas in favour of what is really more akin to data-driven design.

There's some great insight into how the pattern evolves in non-game projects here:

https://softwareengineering.stackexchange.com/a/306983/27143...

That's an awesome article! Thanks for sharing.

The problem with this approach is that systems will need info from multiple components, so at some point you are forced to make the coupling that the ECS was brought in to avoid. For example, the rendering system needs to know entity position. So to which system does the "position component" belong? Not all entities that have a position needs to be rendered, and neither do all renderable entities require movement, and this same issue permeates all aspects of the architecture.

Components do not belong to a system. Any system can access any component. Think of RDBMS stored procedures that operate on all rows matching certain criteria; don't think OO style encapsulated "methods".

The system only operates on entities that have all the components they need. So there won't be one rendering system but several: one for entities that require movement, one for those which do not, etc.

Almost right. You wouldn't necessarily have a separate rendering system for entities that require movement and those that do not.

Instead you would likely have an additional system that operates on entities that have both position and render components and propagates updates from position to render data. The render system for all entities with just a render component would then remain the same.

This can be imagined as systems that work on signatures (a component set or aspect that specifies whether an entity's components match the system's criteria).

A render system would have an aspect of say [RenderComp] and a positionRender system would have an aspect of say [RenderComp, PositionComp]. Note that the positionRender system would not actually render anything, only serving as a propagater of data.

Why does a component need to belong to a system? Why can't the component belong to itself and just be used by multiple systems?

Right, this is the general approach of ECS.

I suggest you read more into component signatures and how systems decide which components to operate on.

Specifically, systems do not own components. Nor do they operate on full entities. Nor is there any coupling.

If you have entities that need to be rendered, you would give them a render component. A render system would render all render components that exist (thus 'rendering the entities' for whom those render components belong to)

If you have entities with positions but not render components, the render system would not operate on those entities.

Similarly if an entity has a render component but no, say, velocity component, it would not be registered to a movementSystem.

Systems that need to propagate data between components would have component signatures that include those components for which they need the data of. So a positionRender system would have an aspect of [PositionComp, RenderComp] and would be the only system to copy over data from one to the other.

There will always have to be a place that decides what object has which components. This should be as close as possible to the 'aggregate root' (a term from DI), and generally in ECS at the point of instantiation of the entity. I believe this question is prompted by a fundamental misunderstanding of ECS.

ECS as you describe it sounds like a good idea, but notice how it is a step away from OO which was supposed to keep code and data in a single encapuslated thing called an "object".

Now our componenents are nearly just plain-old-data and entities are slightly more sophisticated data-structures for tying them together. All the code is now kept is "systems", which are starting to look very much like plain-old modules.

No doubt the OO language will give you some useful tidbits, so that you can have slightly non-trivial getter setters and whatnot. But the design ends up fundamentally procedural -- which I say is good thing.

Yes, ECS is very much not OOP.

> I think the big problem with OOP is that it's designed to simulate the real world

I actually think that it's more designed to reflect (one particular idea of) the way humans construct mental models of the real world.

> Real world objects are a composition of parts

At the lowest level, sure, but if our aren't modelling quantum physics, the “parts” are abitrary artificial divisions (or aggregations), not part of the fundamental nature of the real world, which are no more fundamental than taxonomy (or identity) of the objects they compose.

> In fact, the only reason why a frog is an amphibian is because it has parts all amphibians share.

In a typical taxonomy, that's true, but it's not in a phylogenetic one, which is based on ancestry, not parts.

> It should be entirely possible for me to construct an object that fits the definition of a frog without specifying I'm creating a frog.

OOP allows this (and it's common in dynamic OOP languages, back to Smalltalk), though static class-based OOP (which treats inheritance as type heirarchy) relies on declaration to limit what an object can be used as.

Food for thought. Your comment shows a wide range of knowledge and covers things I haven't thought about.

I was reading about the history of Simula and how the majority of OOP features originated there. It was built as a simulation language, hence the name. I took from that it was designed to simulate the real world - I guess based on the below that's akin to simulation of mental models.

I did briefly think about the quantum mechanics rabbit hole. You make a good point. I'll think about this more. People can tell what a radio is because they have a general idea of what a radio does - has a speaker, volume, aerial. This is what led my thinking.

I'll think more about this.

>It should be entirely possible for me to construct an object that fits the definition of a frog without specifying I'm creating a frog.

This is known as structural typing and TypeScript does exactly this. Two objects with the same properties are the same.

This usually works well, but there are a few issues with this. Number one is related to optimization. The type system that results from using structural typing is unsound. This doesn't matter for typescript since it compiled down to JavaScript which has no types anyways, but for a typical VM executed language there's many optimizations the compiler can't do.

The second issue with structural typing is what I like to call the "mixin problem". If you get too flexible with composition it becomes close to having no type system at all.

Is it true that all structural type systems are unsound? I was under the impression this is a typescript specific problem.

I tried to find the answer and it seems the problem is much more complex than I thought. Rather than bullshit about it I'll just say I have no idea :)

Is structure defined just by type?

Like is all things which only have two integer properties considered the same?

{ Int age; Int weight; }

Would be equal to:

{ Int x; Int y; }

?

Close, any objects with the same properties and types are compatible. The name of the properties and their types need to match.

And this isn't always a good thing. If you have a function dealing with the property 'length' or 'value' for instance, you might as well have no type system because Typescript will allow you to pass in any object with those properties which is almost anything.

While the code will still compile and run like this the type system has failed its purpose of preventing developers from using the wrong types.

I see, sounds interesting. Are the names namespaced? And how would a method know its compatible? Do you type the properties a method needs instead of the object name?

You pretty much act as you do with regular type systems, rarely creating types that are compatible by accident. There is one place however where you use structural typing constantly.

TypeScript is a superset of JavaScript and using "options" objects as method parameters is a common pattern. These options objects are synonymous with anonymous classes and don't have a name, only a shape. Structural typing is one of the strategies TypeScript uses to maintain compatibility with patterns in JavaScript that use these nameless objects.

There are no namespaces. Methods are compatible if they take the same or a subset of the parameters. Objects need to have matching property names and values.

Hum, thanks for the info. I feel curious to try it out. I think names should be namespaced though, that could solve the issue of having a length or value named property. The namespace could distinguish between two values that aren't compatible for example. Though I guess if the types are precise enough, they could embed some of that.

Given an object with a length property with the type a method expects, is there ever a scenario where the method is incorrect?

I'm trying to wrap my head around it: if a method needs only the length property, which is an unsigned int, is there any good reason why it shouldn't accept any object that has that property?

It appears at first that this is a good quality: the code is general whilst obviously avoiding any type errors, including null/undefined errors.

The type system is still working properly in that it will produce code that compiles and runs. For the developer such a behaviour can be misleading. This is compounded by IDE's with intellisense which will suggest passing random objects with the correct properties into the function.

"In this way, OOP would benefit from composition-first, taxonomy after. An object is a thing because of what it has (and this includes behaviour too), not because of what it is or descended from."

A lot of working programmers have figured this out already. Most experienced programmers I know don't use much inheritance.

Exactly and the languages don't express that practice. We get design patterns / DI and maxims like composition over inheritance. Our languages still make it easier to inherit than to compose despite all that.

Plus, my wider point was that in the real world, which is the inspiration for OOP, the taxonomy is artificial and placed onto an object. The taxonomy isn't an inherent part of the object (i.e Dog extends Canidae). The taxonomy is given to an object based on its composition separately i.e a dog is a dog because of some property x, y and z and just so happens that X, y are what makes Canid a Canid and X is what makes a carnivore a carnivore.

Unfortunately OOP languages typically lack sum types, the mathematical dual of product types (objects with just fields). This means subtyping and inheritance is often needed to encode sum types.

In functional languages it's easy to run into difficulties with extending a sum type without changing the defining module.

> It should be entirely possible for me to construct an object that fits the definition of a frog without specifying I'm creating a frog.

The problem with this approach is that different domain experts will have different definitions of what "is" a frog. If you ask a theologist, a molecular biologist, and a zoologist to define a frog, you'll certainly get three different but valid answers.

That's not a "problem" - that just means you have different frogs - each with a well defined criteria.

That's just a problem of context. With the taxonomy separate, the objects can be different things in different contexts. With de facto OOP, you have no hope in hell because the taxonomy is hard coded to the structure of the object itself.

My point is supported by what you say, in fairness. A taxonomy is artificial and separate to the actual object itself. It can and is different based on who defines the taxonomy. My argument is that this is why OOP suffers: it makes the taxonomy inherent to the object and all best OO practice tries to work around that. "Composition over inheritance" anybody?

> That's just a problem of context. With the taxonomy separate, the objects can be different things in different contexts.

Except that you want to share properties between those different contexts, and this is where hell begins. For instance (for a more programming-related problem) say that you have a gui application with graphical objects that map to your frogs,say a frog pond simulation. Now months passes and the boss says "okay, seems that our software interests molecular biologists too, but they need to have another 'molecular frog view' with properties Foobigate and Brozigate to study them properly at the molecular level. Of course the 'molecular frog view' has to be in sync with the 'pond frog view', also they want a simple readable save format.". Now, how do you set up your code so that Joe programmer that comes next week can be operational on the code in three days ?

I love how much this comment makes me think. Thank you!

To be honest, this sounds like a hell hole no matter what you did. It's a complex program that services two domains.

I would say that in the real world, a frog studied in a pond and frog studied at a molecular level share the same properties. A frog is a complex object that has many parts. Naturally for a pond view, you provide the properties needed for that, through composition of smaller objects. If you want to study it on a molecular level, you are really studying the properties, the constituent objects, at a much more granular level (and perhaps more that you didn't need in the simple pond view). It's all still one object.

In fairness, this would be much worse to model in bog standard OOP. Could Joe programmer fair any better there too? Would Joe programmer be working on a macro/molecular simulation in the first place?

As I mentioned above, an Entity Component System would have no issue solving this. You'd add the molecular frog components (foobigate and brozigate) to wherever you create frog entities and then you'd also create and add a system that synchronizes between the entities that have pond frog components and these new components. None of the original code would change minus the instantiation function for a frog entity. Similarly simple change goes for the save format.

I guess what I'm calling for is a language that directly supports ECS :) it's currently a pattern that works well and any good pattern should be one a language feature.

One of the main points of design patterns is composition over inheritance. Composition is also a major part of functional programming.

Yep, exactly! We now have a bunch if OOP languages that provide language features for inheritance making it easy but composition is an emergent property entirely based on existing language features - it's not a language feature itself.

What I'm saying is flip it on its head. Build an OOP language where you have features to make composition easy and separate the taxonomy as a separate thing that shouldn't be tied directly to an object.

Would you say that Scala is close to hitting that target? I've only taken a cursory look at it, but its traits appear to satisfy composition and its type system looks pretty close to being a decoupled taxonomy.

I'm not sure what a full implementation of a separate taxonomy would look like. Duck typing with an algebraic type system that is only applied when you ask for it?

I haven't looked at Scala closely. I'll take a look - thanks for the tip :)

This is something I'm thinking about a lot. I've been wanting to sit down and sketch out what it would look like in terms of syntax / structure. Difficult with 3 kids, wife and a full time job.

I think behaviours should be able to specify taxonomy, which in effect is a name for saying "I only accept objects that do this and have that".

I envisioned a system where it's perfectly possible to work with purely anonymous taxonomies i.e your behaviours specify explicitly what its parameters have in terms of behaviour e.g if an object parsed a string, we could expect that the parameter has just the behaviours needed to do the work e.g length, substring, equality. Or we could just say it wants a string (which is just a separate alias that says an object has those things - like an interface except you don't have to declare you're implementing it).

I think there is value in being able to see an object you want to be part of a taxonomy fits the bill - this would be more like interfaces. Maybe it's better left to static analysis (stop! you're trying to pass an object that doesn't have behaviour X to behaviour Y that expects it).

I don't think what you're saying is really much at odds with many OOP languages. Unless I'm missing something, Ruby's mixins and duck-typing (care about what messages an object responds to rather than it's type) comes awfully close to what you're looking for.

Granted, something like duck-typing is more of a practice or pattern than something that's terribly well supported by the language (it's up to you to put safeguards that the object being passed to you does what you want it to do), but it's certainly possible and describes most well-written Ruby code.

Ruby influenced my opinion.

What I described above wasn't duck typing plus responds_to - maybe it sounds like a whole lot of sugar on that. It was keeping the taxonomy separate, with behavioural sharing through composition only. I was elaborating on how parameters would work - do you allow taxonomies there or keep it separate still?

It's at odds with Ruby because it's still easier to inherit than it is to compose an object. As much as I love the language for its flexibility, it is still based on the idea of coupling the taxonomy with the object itself.

I'm sure an emulation of what I describe is possible to a degree in Ruby.

>One of the main points of design patterns is composition over inheritance.

One of the opening pages of the Design Patterns book (the GoF book) has "Prefer composition over inheritance" (or words to that effect) as the only sentence on that page, right in the middle of it. My guess is that the GoF authors did that to emphasize the importance of that advice, maybe due to having seen too many brittle inheritance-laden hierarchies.

I mentioned this to a client I was consulting to, a couple of years ago, after I saw that he seemed to be using inheritance too liberally, and maybe without thinking if it was needed and the right thing to use for his specific needs. He did get the point, and changed his code from then on.

Different languages encourage different OOP styles e.g., Go language encourages composition.

Though people may argue on the meaning of OOP https://groups.google.com/forum/#!msg/golang-nuts/bSXry29pNo...

Direct link: http://www.purl.org/stefan_ram/pub/doc_kay_oop_en