Yes. Array programming happens to overlap heavily with DOD in modern hardware because of caching and SIMD, but if you were programming an Atari ST it wouldn't.
There are also cases where the optimal data format isn't array oriented because the memory access patterns for the problem in question just require something else.
You also have to think of hot vs cold data, which has nothing to do with arrays.
Eh, I don't think that's a good renaming. Data-Oriented Design is in opposition to Domain-Driven Design (a software development approach that prioritizes modeling software to match a real-world business domain).
OOP tells you to structure your software as objects exchanging messages, and DDD tells you what those objects (or their classes rather) should be.
Similarly, Procedural programming tells you to structure your software as procedures, and DOD tells you what those procedures should operate on.
The focus on the data is the really important part. What is the actual data I'm operating on (without any fluff on top) and what do I need to transform it into? What subsets of that data need to be operated on at any given point in the program? That's the core of DOD.
Then, as a second step, comes the hardware. Now that I know what data I need to operate on, how do I lay it out to best take advantage of the hardware I'm targeting? If you rename the paradigm to "Hardware Oriented Programming", it shifts the focus from data modeling to code (IMO), which is the wrong frame of mind.
For example, virtual calls are slow compared to direct calls, because they screw up branch prediction and often can't be inlined. In HOP, you'd probably ban virtual calls entirely because virtual calls bad.
But in DOD, they honestly probably don't matter at all! Because if you did the data modeling as instructed, and then you laid out the data to best take advantage of the hardware, your virtual function is going to be operating on a pile of data in bulk, making the virtual call cost pure noise.
A lot of it just comes down to KISS and avoiding unnecessary overhead and indirection (like vtables, C++ STL containers etc.) so you're getting the most out of the hardware.
It's fair to mention that DOD is not only getting the most out of the hardware. It also allows the busy work to be avoided. I caught myself a couple of times, when I wanted to make a set of types united by some interface. However, in reality what I could do (and I did eventually) is having several instances of single SOA (one per type) which were processed differently. The addition of a new "type" turned from a good hundred line patch to 20-30 lines
It means instead of building a street object, with car objects that have tire objects as its children and then running through the tree to rotate the wheels you just have an array pointing to exactly the appropriate data type to accomodate the type of wheel rotation you need.
Very often the answer is indeed arrays, but it can easily be something else, depending on the problem. Data driven design is not very complicated, it just means instead of thinking about abstraction you think about the shape the data needs to be in to accommodate the most common transformations you need to do with it.
Have a look at the talk Practical Data-Oriented Design by Andrew Kelly [1]. He covers the following techniques:
1. Indexes instead of pointers. This allows you to avoid alignment of 8 bytes in your structure for x86_64.
2. Storing booleans out-of-band. Booleans cause padding all the time.
3. Struct of Arrays. Based on your question I assume you're familiar with it.
4. Store sparse data in hash maps. I remember one time when it allowed to eliminate inheritance.
5. Encoding the data instead of OOP/polymorphism. I haven't got an occasion to use it. The idea is to add extra tags to avoid boolean properties.
[1] - https://vimeo.com/649009599
- Data-Oriented Design Revisited: Type Safety in the Zig Compiler - Matthew Lugg - https://youtu.be/KOZcJwGdQok?si=YDal2Gwb0IJPFgrI
- Andrew Kelley Practical Data Oriented Design (DoD) - https://youtu.be/IroPQ150F6c?si=F1Z0pLO2W5hbQgpM
- CppCon 2014: Mike Acton "Data-Oriented Design and C++" - https://youtu.be/rX0ItVEVjHc?si=jv4hhTSBh3XH--xQ
- Why You Shouldn’t Forget to Optimize the Data Layout - https://cedardb.com/blog/optimizing_data_layouts/
- Handles are the better pointers - https://floooh.github.io/2018/06/17/handles-vs-pointers.html
- Enum of Arrays - https://tigerbeetle.com/blog/2024-12-19-enum-of-arrays/
- Data oriented design book - https://www.dataorienteddesign.com/dodbook/
- Data-oriented design in practice - Stoyan Nikolov - https://youtu.be/_N5-JjogNXU?si=vhaxYcfE6tl11Sux
- Programming without Pointers - Andrew Kelley - https://www.hytradboi.com/2025/05c72e39-c07e-41bc-ac40-85e83...
- More Speed & Simplicity: Practical Data-Oriented Design in C++ - Vittorio Romeo - CppCon 2025 - https://youtu.be/SzjJfKHygaQ?si=jafavSl2YJWk4vIx
- Rust Handle - https://taintedcoders.com/rust/handles
Yes. Array programming happens to overlap heavily with DOD in modern hardware because of caching and SIMD, but if you were programming an Atari ST it wouldn't.
There are also cases where the optimal data format isn't array oriented because the memory access patterns for the problem in question just require something else.
You also have to think of hot vs cold data, which has nothing to do with arrays.
Can I propose renaming it to Hardware Oriented Programming?
That would be https://martinfowler.com/articles/mechanical-sympathy-princi...
Eh, I don't think that's a good renaming. Data-Oriented Design is in opposition to Domain-Driven Design (a software development approach that prioritizes modeling software to match a real-world business domain).
OOP tells you to structure your software as objects exchanging messages, and DDD tells you what those objects (or their classes rather) should be.
Similarly, Procedural programming tells you to structure your software as procedures, and DOD tells you what those procedures should operate on.
The focus on the data is the really important part. What is the actual data I'm operating on (without any fluff on top) and what do I need to transform it into? What subsets of that data need to be operated on at any given point in the program? That's the core of DOD.
Then, as a second step, comes the hardware. Now that I know what data I need to operate on, how do I lay it out to best take advantage of the hardware I'm targeting? If you rename the paradigm to "Hardware Oriented Programming", it shifts the focus from data modeling to code (IMO), which is the wrong frame of mind.
For example, virtual calls are slow compared to direct calls, because they screw up branch prediction and often can't be inlined. In HOP, you'd probably ban virtual calls entirely because virtual calls bad.
But in DOD, they honestly probably don't matter at all! Because if you did the data modeling as instructed, and then you laid out the data to best take advantage of the hardware, your virtual function is going to be operating on a pile of data in bulk, making the virtual call cost pure noise.
A lot of it just comes down to KISS and avoiding unnecessary overhead and indirection (like vtables, C++ STL containers etc.) so you're getting the most out of the hardware.
It's fair to mention that DOD is not only getting the most out of the hardware. It also allows the busy work to be avoided. I caught myself a couple of times, when I wanted to make a set of types united by some interface. However, in reality what I could do (and I did eventually) is having several instances of single SOA (one per type) which were processed differently. The addition of a new "type" turned from a good hundred line patch to 20-30 lines
It means instead of building a street object, with car objects that have tire objects as its children and then running through the tree to rotate the wheels you just have an array pointing to exactly the appropriate data type to accomodate the type of wheel rotation you need.
Very often the answer is indeed arrays, but it can easily be something else, depending on the problem. Data driven design is not very complicated, it just means instead of thinking about abstraction you think about the shape the data needs to be in to accommodate the most common transformations you need to do with it.
Yes