[slopinthebag]

The problem is that there are a lot of subtleties to an ECS that these frameworks solve, and they perform better than a naive approach too. Your solution of a particles struct doesn’t even support a fundamental feature of ECS’s which is runtime composition. It’s really a different solution altogether, which is fine but it’s not a replacement for an ECS.

[inigyou]

Often you don't have runtime composition and don't need it. By prematurely generalizing you're venturing close to OOP territory.

[slopinthebag]

“Prematurely generalizing” is now an OOP thing? Are we just using OOP as a term for anything bad now?

Ooh here is a controversial one. DOD is premature optimization. Most programs don’t have enough data where the storage and access is a factor for performance. In fact it might be slower to use DOD.

[inigyou]

I don't think that's all that controversial. DOD comes out of the field of video games where people were frustrated by only being able to process ten thousand things sixty times per second and wanted to process ten million things sixty times per second. While it's also been used to speed up things like the Zig compiler, it's definitely not necessary for all software.

One of the ideas in OOP that DOD is explicitly refuting is pretending not to know what your program does. You know which subtypes exist in your program and you shouldn't treat them generically as supertype instances except when that is actually optimal. On this axis, both ECS ideology and OOP ideology are opposite to DOD ideology. ECS happens to align with DOD in that it prefers big linear arrays, but it does not align in pretending not to know what combinations of arrays are used, which is similar to pretending not to know what subtypes of Shape exist.

[slopinthebag]

You don't always know what subtypes will exist, either at runtime or in future iterations of the program.

[HelloNurse]

No amount of ideology can fill L1 cache.

[pdpi]

> Are we just using OOP as a term for anything bad now?

Different paradigms come with different pathological cases. I've had to deal with Scala programmers whose notion of FP is making everything generic on the Monad it abstracts over, even when it'll only ever be instantiated on the one effect system the team uses. Nonsensical levels of generality is one of the classic OOP pathologies, and is the reason why we have aberrations like the AbstractSingletonProxyFactoryBean[0].

0. https://docs.spring.io/spring-framework/docs/current/javadoc...

[inigyou]

oh my god. I thought that class was just a joke, but it's real.

[FpUser]

>"Nonsensical levels of generality is one of the classic OOP pathologies"

I think it has nothing to do with OOP which I find very convenient for some domains and not so much or even opposite for others. These "Nonsensical levels" of anything is a disease which is called Architecture Astronauts Syndrome and victims apply it to any paradigm

[inigyou]

OOP can be convenient for prototyping a game because you can just write new stuff at high velocity like "yeah a cow is a pig but it's brown and drops leather, a skeleton is a zombie that shoots arrows, and a client is just a server with graphics". Figuring out the right decomposition right from the start can be harder.

[HelloNurse]

It is usually possible to design a representation where cows and pigs are the same thing, either Animal class instances or equally unified other data structures, and their differences are data (e.g. weight, length, one of several colour patterns).