13 ms·

I've read quite a few articles about DOD. I get how DOD is great but there are reasons OOP is still around (surely?) I suppose I'm still hung up on, what are t

I've read quite a few articles about DOD. I get how DOD is great but there are reasons OOP is still around (surely?) I suppose I'm still hung up on, what are the benefits of OOP that I'm missing? It seems like there are reasons OOP is so ingrained. I can see a couple of reasons that are environmental. For instance, OOP is taught in schools because students are often taught to program before they're taught about computer architecture - thus DOD would be lost on them. It would be a huge barrier to entry to introduce cache hit rates as a design concern when people are just learning what a class is (in the current standard model of CS education). Still, it feels like there are other practical reasons to keep OOP around. Perhaps OOP is the React Native of design patterns - poor performance but quicker to write and add new members to. It does seem like there are also legitimate concerns about refactorability and extensibility of DOD code. Anyone have any more refined ideas here?

jayd16 6y ago
They're not really exclusive concepts and you don't want to bother with DOD if your n is low. I would go as far as to say most DOD implementations are done along side the use of objects.
- blovescoffee 6y ago
  Sure, although there's room for distinction between programming with objects and OOP.
adamnemecek 6y ago
I think oop is easier to understand in small examples but gets really inscrutable as your code base grows so you only start questioning oop if you have worked on large code bases. Also the lack of dod/ecs languages is a problem. I realized the other day that row polymorphism is the type theoretical concept that would make this work. https://en.wikipedia.org/wiki/Row_polymorphism https://en.wikipedia.org/wiki/Row_polymorphism
- mdtusz 6y ago
  Partially, but DOD like in the article examples work great when you have a "rigid" architecture like a game where having a struct to contain vecs/arrays of player attributes makes sense. This can break down when your "objects" require more flexibility and are used in multiple different contexts where an aggregate `PlayerState` struct doesn't play nicely. Not to say that DOD is bad, just that it shouldn't always be the go-to choice. Rust _does_ make this sort of design much nicer to work with because you can in many ways have your cake and eat it too using `from` and `into` and go back and forth from DOD to OOP type structures.
  - runevault 6y ago
    ECS style DOD arguably makes putting things together easier though, because instead of having to update your actual object when you want to make a change, you only have to add the right component that contains the functionality you need to the given entity ID.
    - adamnemecek 6y ago
      And don't get me started once you have some hierarchies. Sometimes a object changes and you need to notify a parent of this change. OOP really sucks at this.
      - nikki93 6y ago
        It seems like in these cases often at least in frame-based systems like games it makes sense to sort your data in a parent->child partial order, then visit in that (or reverse depending on which algo) order propagating changes, then do another pass later and so on. It's just nice that you can think about these things once you're in DoD-land.
erichocean 6y ago
> It does seem like there are also legitimate concerns about refactorability and extensibility of DOD code. On the contrary, that's why people adopt DOD designs. It's way easier to add new stuff without breaking existing code/designs in a way that harms them.
- blovescoffee 6y ago
  If your data changes then won't you need to refactor more than if your data changes in OOP? I suppose "data changing" is an arbitrary measurement but I think that's what people refer to when they talk about refactoring DOD vs OOP.
  - Arelius 6y ago
    Likely, yes, but the corollary is if your data structure stays similar and well defined, then you'll have smaller, cleaner and less refactors for reasons that are unrelated to a fundamental shift in your actual data
genuine_smiles 6y ago
A lot of languages have OOP built into them. If want to use patterns like polymorphism it’s the tool on hand. Associating data with functions is helpful for organization as well.
- adamnemecek 6y ago
  In DOD you have row level polymorphism.
cogman10 6y ago
DOD generally implies a high level of coupling on the system. That's it's biggest weakness. It also pushes even more data management problems onto programmers which makes it easy to get things wrong. You take those downsides and you trade them for higher performance. Now, that doesn't mean that you can't have hybrid systems and get most of the benefits of both worlds. It does, however, mean that you will end up with a more complex system to manage and maintain. A simple OO system is relatively easy to craft without a whole lot of ceremony. That's the prime benefit of OO.
- jessermeyer 6y ago
  'The hardware is the platform' is the DOD mantra. It's not a weakness to integrate more information about the problem space into the solution. It's engineering. To _ignore_ information about the problem space is certainly a weakness, and is partly responsible why the Windows boot time appears to be a cosmological constant.
  - SquishyPanda23 6y ago
    > It's not a weakness to integrate more information about the problem space into the solution. It's engineering. You want your solution to depend on the right abstract model of the problem, not on the particulars of the problem. Otherwise your solution is difficult to extend, and is generally expensive and error prone to change when your problem changes, which happens with 100% probability.
    - JesseMeyer 6y ago
      If a well established abstraction solves the problem, then that's just a particular known about the solution space. If your data changes, your problem changes. We only ever solve particular problems, given the distribution, shape and density characteristics of input data.
- adamnemecek 6y ago
  DOD couples less than OOP. What is data management in this context?
mamcx 6y ago
Is more than OOP. Look at this as the difference between OLAP/OLTP databases: DOD is OLAP(Columnar) that make easy to do "query" by columns but awkward to do piece meal updates and OOP/Row-nar(?) code stay because frankly is the default everywhere. And far easier for make updates. Iterate by rows is far more common that by just "a column". Also, constant update of the rows is more common that have a static, full materialization of the data that only need to be queried. So, doing DOD only work in some scenarios, but do "by rows" is the common one. P.D: I tried to go full columnar building a relational language, but get very obvious very fast that it not work for the general case. Is telling that kdb+ (probably the biggest proponent in the area) work in a OLAP-like niche...
- Jtsummers 6y ago
  I was going to write something similar. The example in this article is a comparison between row-oriented and column-oriented approaches, not OOP and DOD. Which you prefer depends on the operations you expect to perform during program execution. If you generally only add new entities, and generally perform operations on all entities (or large subsets) and specifically only need some columns, then the column-oriented approach is more likely what you want. If you find you delete entities frequently enough, or operate on individual entities more than groups, then row-oriented may be better. Performance will improve (deletes are expensive in arrays/vectors) and code may be cleaner. There are lots of other factors, but these are the bigger ones (IME).
CyberDildonics 6y ago
"OOP" is really three different things that people conflate together. 1. Making data structures as tiny databases with an interface that simplifies storing and retrieving data correctly (no transformations in the class itself to other data types hopefully to minimize dependencies!) 2. The school taught java/old C++ debacle of inheritance. This is where things fall apart. Inheritance means not only dependencies but opaque dependencies. It almost always means pointer chasing and lots of allocations. It used to be necessary because it was the only way to get generic containers. The speed hit to use a chain of pointers was also much smaller. In modern times this destroys performance and is not needed due to templates. 3. Message passing - 'at a certain scale, everything becomes a network problem'. I think the flexibility in having this integrated into the core of a language like smalltalk is not a good trade off, but I do think message passing at a courser architectural level offers large benefits without limiting the speed of more granular and fundamental data structures and functions. I think OOP will always be debated in a circle because people conflate these three aspects. The first I think is extremely useful and vital. The second I think is obsolete. The third I think should be treated as a higher level architecture approach with large chunks of data passed around to large non-trivial modules/libraries/nodes/plugins etc. The higher level can be more dynamic and flexible because the overhead for a flexible structure is much smaller if it is done with large chunks of data and not integrated into a language and used for vectors / hash maps / one line math functions, etc.
jbjbjbjb 6y ago
OOP isn’t necessarily slower. One thing you get is lazy evaluation for free. There’s no better performance gain that no computation. It’s also much easier to extend the types than in functional programming (where it is easier to extend the functions). I find OOP is a lot better for programming in the large too, interfaces and other abstractions are really useful as a project grows.
indymike 6y ago
At first I thought that DOD was a new programming paradigm. It is not. DOD is a very smart optimization for dealing with processing arrays. So in short, OOP isn't going away this week.

jayd16 6y ago

They're not really exclusive concepts and you don't want to bother with DOD if your n is low. I would go as far as to say most DOD implementations are done along side the use of objects.

blovescoffee 6y ago
Sure, although there's room for distinction between programming with objects and OOP.

adamnemecek 6y ago

I think oop is easier to understand in small examples but gets really inscrutable as your code base grows so you only start questioning oop if you have worked on large code bases. Also the lack of dod/ecs languages is a problem. I realized the other day that row polymorphism is the type theoretical concept that would make this work. https://en.wikipedia.org/wiki/Row_polymorphism https://en.wikipedia.org/wiki/Row_polymorphism

mdtusz 6y ago
Partially, but DOD like in the article examples work great when you have a "rigid" architecture like a game where having a struct to contain vecs/arrays of player attributes makes sense. This can break down when your "objects" require more flexibility and are used in multiple different contexts where an aggregate `PlayerState` struct doesn't play nicely. Not to say that DOD is bad, just that it shouldn't always be the go-to choice. Rust _does_ make this sort of design much nicer to work with because you can in many ways have your cake and eat it too using `from` and `into` and go back and forth from DOD to OOP type structures.
- runevault 6y ago
  ECS style DOD arguably makes putting things together easier though, because instead of having to update your actual object when you want to make a change, you only have to add the right component that contains the functionality you need to the given entity ID.
  - adamnemecek 6y ago
    And don't get me started once you have some hierarchies. Sometimes a object changes and you need to notify a parent of this change. OOP really sucks at this.
    - nikki93 6y ago
      It seems like in these cases often at least in frame-based systems like games it makes sense to sort your data in a parent->child partial order, then visit in that (or reverse depending on which algo) order propagating changes, then do another pass later and so on. It's just nice that you can think about these things once you're in DoD-land.

erichocean 6y ago

> It does seem like there are also legitimate concerns about refactorability and extensibility of DOD code. On the contrary, that's why people adopt DOD designs. It's way easier to add new stuff without breaking existing code/designs in a way that harms them.

blovescoffee 6y ago
If your data changes then won't you need to refactor more than if your data changes in OOP? I suppose "data changing" is an arbitrary measurement but I think that's what people refer to when they talk about refactoring DOD vs OOP.
- Arelius 6y ago
  Likely, yes, but the corollary is if your data structure stays similar and well defined, then you'll have smaller, cleaner and less refactors for reasons that are unrelated to a fundamental shift in your actual data

genuine_smiles 6y ago

A lot of languages have OOP built into them. If want to use patterns like polymorphism it’s the tool on hand. Associating data with functions is helpful for organization as well.

adamnemecek 6y ago
In DOD you have row level polymorphism.

cogman10 6y ago

DOD generally implies a high level of coupling on the system. That's it's biggest weakness. It also pushes even more data management problems onto programmers which makes it easy to get things wrong. You take those downsides and you trade them for higher performance. Now, that doesn't mean that you can't have hybrid systems and get most of the benefits of both worlds. It does, however, mean that you will end up with a more complex system to manage and maintain. A simple OO system is relatively easy to craft without a whole lot of ceremony. That's the prime benefit of OO.

jessermeyer 6y ago
'The hardware is the platform' is the DOD mantra. It's not a weakness to integrate more information about the problem space into the solution. It's engineering. To _ignore_ information about the problem space is certainly a weakness, and is partly responsible why the Windows boot time appears to be a cosmological constant.
- SquishyPanda23 6y ago
  > It's not a weakness to integrate more information about the problem space into the solution. It's engineering. You want your solution to depend on the right abstract model of the problem, not on the particulars of the problem. Otherwise your solution is difficult to extend, and is generally expensive and error prone to change when your problem changes, which happens with 100% probability.
  - JesseMeyer 6y ago
    If a well established abstraction solves the problem, then that's just a particular known about the solution space. If your data changes, your problem changes. We only ever solve particular problems, given the distribution, shape and density characteristics of input data.
adamnemecek 6y ago
DOD couples less than OOP. What is data management in this context?

mamcx 6y ago

Is more than OOP. Look at this as the difference between OLAP/OLTP databases: DOD is OLAP(Columnar) that make easy to do "query" by columns but awkward to do piece meal updates and OOP/Row-nar(?) code stay because frankly is the default everywhere. And far easier for make updates. Iterate by rows is far more common that by just "a column". Also, constant update of the rows is more common that have a static, full materialization of the data that only need to be queried. So, doing DOD only work in some scenarios, but do "by rows" is the common one. P.D: I tried to go full columnar building a relational language, but get very obvious very fast that it not work for the general case. Is telling that kdb+ (probably the biggest proponent in the area) work in a OLAP-like niche...

Jtsummers 6y ago
I was going to write something similar. The example in this article is a comparison between row-oriented and column-oriented approaches, not OOP and DOD. Which you prefer depends on the operations you expect to perform during program execution. If you generally only add new entities, and generally perform operations on all entities (or large subsets) and specifically only need some columns, then the column-oriented approach is more likely what you want. If you find you delete entities frequently enough, or operate on individual entities more than groups, then row-oriented may be better. Performance will improve (deletes are expensive in arrays/vectors) and code may be cleaner. There are lots of other factors, but these are the bigger ones (IME).

CyberDildonics 6y ago

"OOP" is really three different things that people conflate together. 1. Making data structures as tiny databases with an interface that simplifies storing and retrieving data correctly (no transformations in the class itself to other data types hopefully to minimize dependencies!) 2. The school taught java/old C++ debacle of inheritance. This is where things fall apart. Inheritance means not only dependencies but opaque dependencies. It almost always means pointer chasing and lots of allocations. It used to be necessary because it was the only way to get generic containers. The speed hit to use a chain of pointers was also much smaller. In modern times this destroys performance and is not needed due to templates. 3. Message passing - 'at a certain scale, everything becomes a network problem'. I think the flexibility in having this integrated into the core of a language like smalltalk is not a good trade off, but I do think message passing at a courser architectural level offers large benefits without limiting the speed of more granular and fundamental data structures and functions. I think OOP will always be debated in a circle because people conflate these three aspects. The first I think is extremely useful and vital. The second I think is obsolete. The third I think should be treated as a higher level architecture approach with large chunks of data passed around to large non-trivial modules/libraries/nodes/plugins etc. The higher level can be more dynamic and flexible because the overhead for a flexible structure is much smaller if it is done with large chunks of data and not integrated into a language and used for vectors / hash maps / one line math functions, etc.

jbjbjbjb 6y ago

OOP isn’t necessarily slower. One thing you get is lazy evaluation for free. There’s no better performance gain that no computation. It’s also much easier to extend the types than in functional programming (where it is easier to extend the functions). I find OOP is a lot better for programming in the large too, interfaces and other abstractions are really useful as a project grows.

indymike 6y ago

At first I thought that DOD was a new programming paradigm. It is not. DOD is a very smart optimization for dealing with processing arrays. So in short, OOP isn't going away this week.