Data Oriented Design – first chapter (2018) | Hacker News Reader

Data Oriented Design – first chapter (2018)

dataorienteddesign.com

67 pointsjesseduffield19 comments

Past related discussions:

Data-Oriented Design (2018) - https://news.ycombinator.com/item?id=20380397 - July 2019 (37 comments)

Data-Oriented Design (2013) - https://news.ycombinator.com/item?id=11064762 - Feb 2016 (8 comments)

Also:

Data-oriented design or why you might shoot yourself in the foot with OOP (2009) - https://news.ycombinator.com/item?id=27658706 - June 2021 (362 comments)

Some code snippets and images would really help here. Also some more concrete examples.

I understand the main point that data is everything, but the author's arguments are hard to learn and go over my head.

Agreed. When they criticize the OOP approach to modelling game objects, they really needs to give an example of how they think it should be done using the data approach. There are a dozen ways to do this that they may be referring to, I’m not sure which it is

The wording makes it seem like they are criticizing objects because encapsulation makes the contained data less reusable. Well… that’s the whole point of encapsulation. I think the author is trying to say some things and it’s just not coming through as clearly as they intended

The entire rest of the book provides examples. There’s even a direct comparison between initializing a scene in an OOP way vs a DOD way in the next chapter.

Interesting, thanks for letting me know, I’ll read that

Go to any other chapter for plenty of code snippets. The first chapter is more meant to motivate than explain.

For anyone interested into very light forays of DoD in C++, I've put out this library recently which allows to have an "object" API on top of an array-based storage (AoS interface / SoA implementation): https://github.com/celtera/ahsohtoa

I found this chapter to be a good primer on DOD and how OO runs into trouble whenever changes need to be made

To be honest i wish there was some sort of situational Design Paradigm - the VIM of languages. OO in the design of the Structures/Debug-Data Representation, DOD in the structures and algos, functional whenever the programmer itself is represented (the "marshallers and handlers" in OO.)

Somewhere in this triangle of worlds, there is a optimum of speed, debug and reason ability and beautiful code with minimal repetition..

Can you just use a multi-paradigm language to do this?

I’ve found that multi-paradigm languages are often frustrating because they don’t enforce constraints.

One of the advantages of a language like Erlang is that it mandates immutable data, and can both optimize for that and give the developer an easier time reasoning about where changes can and can’t occur.

Python teases with its newer functional features, but any time you pass a data structure off to code outside your control you have no guarantees about what will happen to it.

> One of the advantages of a language like Erlang is that it mandates immutable data, and can both optimize for that and give the developer an easier time reasoning about where changes can and can’t occur.

Isn't that just the keyword "const" in C++? Its not perfect but if you need const the keyword really helps ensuring you 'pass' the const concept all the way down your data to its roots.

You can also have immutable data in Java. Instead of implementing both "setFoo" and "getFoo", you simply implement "getFoo".

It goes much deeper than that.

For example, again referencing Erlang since that's the only FP language I'm well-versed in, immutable data + pattern matching means that there are assertions on practically every line of code in production.

In C++, any "const" data can only have "const" operations operate upon them.

    const int x = 20;
    x = 30 ; // Compile Error, not a const operation.
    int y = x + 20; // Allowed

If you have a class:

    class Foo{
        public:
        const int x;
        int y;

        Foo(int initial): x(initial), y(initial){
        }
        
        void setY(int value){
            y = value;
        }

        int getXPlusY() const{
            return x + y;
        }
    };

    Foo f(20); // Allowed
    f.x = 30; // Compile Error, not a const-operation
    int y = f.x + 30; // Allowed

    const Foo f2(20); // The f2 object is now const. Non-const routines are no longer allowed
    f2.setY(30); // Not a const-routine.
    int bar = f2.getXPlusY(); // Allowed, getXPlusY is a const-function

-----------------

So yes. Every single line of code you write will be double-checked by the compiler to see if it is "const-correct". That's the advantage of multi-paradigm languages like C++. Its not "pure", but it implements ideas like immutability from other languages.

That gives you immutability on that instance, but the benefits are diminished since the language is not immutable-first. If it were, I’d expect f2.setY(30) to return a new immutable instance of Foo with x == 20 and y == 30. As it stands, there’s not a reliable way to get “an immutable Foo instance with everything the same except for y, which has this new value.”

For a class with two properties, you can make a new constructor that initializes both, though it’s a bit unwieldy. It becomes unworkable when you have five or ten properties. A more data-oriented approach would be to use a key/value map, and have standard functions to “update” map members by returning new maps with the “updated” value(s). Those libraries probably exist for C++, but you have to enforce their use, whereas languages that are built around those concepts provide stronger guarantees from the outset.

I think macintux is referring to something like this:

  get_exactly_n_or_crash(N) ->
    {N, Data} = get_data(N).

Suppose get_data will get N or less pieces (if N pieces of data aren't available) of data and return, as a tuple, both the amount of data obtained and the data. The above assignment is actually part of Erlang's pattern matching, the second use of N (on the LHS of the =) is not actually an assignment, it's a check. If get_data returned less than N pieces of data, the program would crash (which you can catch and respond to) at that point.

Specificity and examples are critical and the article lacks both. It's somewhat ironic that the author talks about the importance of data yet offers few examples and datapoints of where this paradigm works and doesn't work.

Without specificity, the merits of the design are not falsifiable.

That's chapter one, not a single standalone article. You can read more by clicking on "contents" at the top or following this link: https://dataorienteddesign.com/dodbook/node1.html.

Reply on news.ycombinator.com