Data-oriented design
by Mr Richard Fabian · first published 2018
18mentions
12recommended by
12HN commenters
2019–2026first – last mentioned
100% recommend
Affiliate links. As an Amazon Associate I earn from qualifying purchases.
Mentions per year
What Hacker News says
Related books
2007–2026Domain-Driven Design
Eric Evans
Recommended by 104 · mentioned by 191104 recommend · 191 mention104 recommend · 191104 recommend
2008–2026Working effectively with legacy code
Michael C. Feathers
Recommended by 186 · mentioned by 234186 recommend · 234 mention186 recommend · 234186 recommend
2018–2026A Philosophy of Software Design
John K. Ousterhout
Recommended by 163 · mentioned by 232163 recommend · 232 mention163 recommend · 232163 recommend
I agree. Perhaps also known as "data-oriented design". Decompose entities into components by modelling the data in a normalised way, as is done when modelling for relational databases. Group together similar data as records in homogeneous arrays, and batch process it without need for OOP polymorphic branching etc. Further reading/viewing, somewhat gamedev oriented (as is the author of this articl
on “Handles are the better pointers (2018)” ↗Andrew Kelley (ziglang lead) recommended Data-Oriented Design (think: Mechanical Sympathy) on twitter once [0]. I read the first few chapters and found it to be pretty neat [1]. Besides, JavaScript: The Good Parts remains one of the best programming books I've read (direly in need of a new edition). [0] https://archive.is/199Eo [1] book: http://www.dataorienteddesign.com/dodbook/dodmain.html /
on “Software engineering books to read and reread” ↗This may be a useful example for a different approach: http://www.dataorienteddesign.com/dodbook/ Particularly the chapter "Relational Databases" which compares to programming with sets in databases. This book doesn't tell you to program as if you worked with SQL, but draws inspiration from it and makes a comparison.
on “It’s time to move on from OOP?” ↗See also: Richard Fabian's "Data-Oriented Design" book. The fourth chapter is about component-based objects, and the preceding chapters about relational databases and existential processing are relevant. http://www.dataorienteddesign.com/dodbook/ Prior HN discussion: https://news.ycombinator.com/item?id=20380397
on “A Thought Experiment: Using the ECS Pattern Outside of Game Engines” ↗>However, there are certain situations where I cannot imagine working without OOP. (...) Similarly, a computer game, having an EnemyDemon inherit from Enemy, so that it has .kill(), .damage(), and properties for health, speed etc.? You'd be surprised. This is much cleaner, and more efficient too: https://medium.com/ingeniouslysimple/entities-components-and... more in depth: https://www.dataorie
on “OO in Python is mostly pointless” ↗This has been a recognized problem for game devs for a while and recently Unity introduced DOTS to gain performance. From what I understand, doing traditional OOP means going through a lot of pointers to find information. If you put everything into arrays instead, you reduce the time spent looking up things. https://unity.com/dots IIRC, this is the textbook that unity pulls from if you want to l
on “OO in Python is mostly pointless” ↗Andrew writes [1]: I have been reading Richard Fabian's book, Data-Oriented Design, and finally things started to "click" for me. I've had these ideas swirling around in my head for years, but only recently do I feel like I have an intuitive grasp on how modern CPUs work, especially…
on “Aro: A C compiler written in Zig” ↗reduce the signal to noise ratio of your cache reads with this one weird trick! data-oriented game engine developers hate him! more seriously, resources explaining why and how not to do this: CppCon 2014 Mike Acton Data Oriented Design and C++ https://www.youtube.com/watch?v=92KFSD3ObrY Richard Fabian's book: https://www.dataorienteddesign.com/dodbook/ Handmade Seattle 2021 Andrew Kelley A Pr
on “Riot: Source code for League of Legends and TFT were exfiltrated by attackers” ↗…in my career, but for me, right now, I'm loving every minute of it. The biggest issue I've faced (beyond the obvious issues of getting anything to work at all), is how to organize the concepts. The "Data-Oriented Design" folks have had a huge impact on that. Specifically, talks from Andrew Kelley, Mike Acton and the book by R. Fabian. The second thing is registers. Just toss the HAL mess, pick up the Reference Manual…
on ““C is quirky, flawed, and an enormous success” – Dennis Ritchie” ↗I recommend reading this book on Data Oriented Design[0] since the underlying reason ECS has been widely adopted is because, written correctly, an ECS system can take full advantage of modern hardware. Most ECS vs OOP blogs come at it from a perspective that I personally find flawed. OOP has the tendency to have objects layed out poorly in memory which prevent programmers from utilizing SIMD instr
on “Advice for new software devs who've read all those other advice essays” ↗In addition to Mike Acton's talk, there is also the "DOD Book": https://www.dataorienteddesign.com/dodbook/
on “Beyond Clean Code” ↗see also: Richard Fabian's data-oriented design book -- the chapter on existential processing discusses enums https://www.dataorienteddesign.com/dodbook/node4.html Rough idea: model everything as relational data - define 1 table for each state. membership of a record in the table corresponding to state X implies that record is in the given state X. > the reason why you would put an enum in tabl
on “Enum of Arrays” ↗Look for data-oriented design [0] (not to be confused with domain-driven design) in addition to ECS. [0] https://www.dataorienteddesign.com/dodbook/
on “The Big OOPs: Anatomy of a Thirty-Five Year Mistake” ↗I think I had a pretty good understanding of set theory through programming, and although I tried to get into the more mathematical side of it, I found most things to be 1. trivial (because I was used to thinking in lists, sets, hashmaps, etc.), or 2. irrelevant to me. The latter was a shame, because I've always liked the abstraction of math, but I couldn't help but feel I wasn't learning anything
on “Learn SQL Once, Use It for 30 Years” ↗> SoA is not universally better. This is an important part of Data-oriented Design: the representation of the data should be pragmatically tied to its access patterns, not dogma. Richard Fabian's DoD book gives the example that (x,y,z) is almost always better as a classic array-of-structs rather than a struct-of-arrays, because if you're accessing one dimension, you probably are want to process
on “Every Byte Matters” ↗