Comment by PessimalDecimal

1 day ago

This seems like a particular branding on cache-aware data structures and algorithms. Is there more to it?

One good example of DoD which isn't CPU-cache-related is relational databases. When designing a CRUD application, the Data-Oriented way of doing it is to figure out what data you will be storing and how to organize that data to minimize access times, which is what you're doing when you design the DB schema.

An example of failing to follow DoD is the N+1 query problem: a programmer builds an abstraction that operates on individual DB rows, but "where there's one, there's more than one": you will inevitably be running that code in a loop so that you can process multiple rows. If instead the programmer had abstracted over groups of rows, then per-item query overheads suddenly become per-batch overheads.

I consider it generally the ideology of anti-OOP. While OOP ideology teaches you to structure the program after the problem it solves, DOD ideology explicitly teaches you to throw all that away and think about what runs fastest on the computer. Maybe it should be called Computer-Oriented Programming or Hardware-Oriented Programming. The specifics very a lot but the top-level ideology of "fuck OOP" is consistent.

People posted a wide variety of specific ideas under my other comment: https://news.ycombinator.com/item?id=49061421

  • > While OOP ideology teaches you to structure the program after the problem it solves

    I completely disagree with this characterization. OOP teaches you a synthetic set of concepts (go4) and then asks you to solve problems in terms of that.

    And the reason why the canonical bird as a subclass of animal doesn’t work, is it’s extremely difficult to divide the world into strict categories (are you Aristotle). So the solution is to organize virtually rather than around natural traits.

    The most natural way to solve a programming problem is a big list of instructions with if/else and goto. It’s very learnable, even for young children.

I actually see ECS as a subset of the relational data model. It's effectively binary relations, in database / E.F. Codd terms.

When you look at it from that angle, rather than as an optimization technique, it makes it clear there is actually an elegant programming model here.

Unfortunately game engine programmers tend to think databases are super uncool and not relevant. They could actually learn a lot.

"flecs" pulls in some concepts from the relational algebraic world in that it has some sense of joins, etc. but it's a bit ad hoc.

The ultimate "data oriented design" game engine could be a high speed, GPU/SIMD accelerated, in-memory Datalog engine. And then the game world expressed in Horn clauses and logic.

https://github.com/timbran-project/mica is some of my playing in this area.