Comment by slopinthebag
1 day ago
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.
Often you don't have runtime composition and don't need it. By prematurely generalizing you're venturing close to OOP territory.
“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.
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.
2 replies →
> 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...
3 replies →