Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Principles of Data Oriented Programming

blog.klipse.tech

Post reply on HN
Print view View original

111–120 of 139 posts

Re: Principles of Data Oriented Programming

#111

Post by hunterloftis »

joshlemer wrote: post #101
slifin wrote: post #42

This talk kind of alludes to the data driven stuff at the end: https://youtu.be/vK1DazRK_a0?t=774 It's a shame the code examples are just the fp and oop solutions not how it could look in a data oriented way

In his refactoring of the JS game, I was with him until about 80% through his refactor, but in the change he describes from about 50:50 - 51:00, he's actually changing the meaning of the game. Instead of printing after each turn, he's running all turns, then printing them all out at once. This is a very different behaviour and I think it's glossing over / copping out from the difficulties of applying FP in side-effec…

...or simulating the world every 16 ms as is typical in a "real" game.

You can bridge that gap by taking periodic snapshots of the reduced state, which is a useful pattern in distributed game development where you sometimes have to back-track and re-simulate when input arrives over the network.

Re: Principles of Data Oriented Programming

#112

Post by hakre »

andi999 wrote: post #32
piokoch wrote: post #17

Principle #2 always bothers me. "Model the data part of the entities of your application using generic data structures (mostly maps and arrays)." and example function createAuthorData(firstName, lastName, books) { return {firstName: firstName, lastName: lastName, books: books}; } For a simple, obvious object like "person" it might work, but for a complicated domain object with many other composed objects this starts…

Usually a map can be fine, but isnt it a maintenance nightmare. At least if you change an object, the compiler will complain if an attribute is not found, but this leads to runtime error/ or bad behaviour

Yes, for sure it is. But what is the alternative? A compiler can only complain on a monolith, it can't scratch boundaries out of the system it compiles (and still within that monolith, encapsulated system the data might be inconsistent).

For distributed systems this has been solved in the last two decades (if not even longer), but still systems are pressing against formality, how come?

Continue to write the code to deal with the (always changing) data, maybe that's it when diving data apart from code (:OP/DO#1 ; Perlis 9. It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures.).

Re: Principles of Data Oriented Programming

#113

Post by valenterry »

joe_the_user wrote: post #106
ummonk wrote: post #96

Earlier quoted context omitted.

I think the principles do basically summarize data oriented programming. Particularly, principle 1 is important since it is the exact opposite of OOP's insistence of encapsulation, and is possibly the biggest reason DOP works so much better than OOP.

Evidence that "DOP works so much better than OOP" is scant imo. The rise and fall of paradigms that present themselves as panaceas is instructive. You have "structured programming", "object oriented programming", "functional programming" and now "data oriented programming". What I'd like to see is paradigms paired with "where this works well" rather than paradigms sold based on "this will solve the software crisis",…

It's not so much a rise and fall rather than refinement.

You still use if/then/else and repetition and subfunctions in OOP. But you restrict and replace some of their previous usage.

Same for functional programming: you take OOP but remove all the sideeffects. You still have objects which encapsulate data which can only be accessed in a certain way and can behave polymorphic. Mind that inheritance was never really part of OOP in general.

Now about DOP - not sure what exactly it adds on top of FP or if it is even an established and well defined term. Doesn't look to me like it, looks more of a bundle of recommendations right now.

Re: Principles of Data Oriented Programming

#114

Post by hakre »

andi999 wrote: post #53
acarabott wrote: post #49

Earlier quoted context omitted.

Adding a version field can be useful to avoid this. Particularly if your entire state is stored in one object.

Agree. But then every function using the map has to query the versiom field?

Who says there is only one version field?

Re: Principles of Data Oriented Programming

#115

Post by zmmmmm »

ajuc wrote: post #89
jmull wrote: post #72

I don't think these principles add up to something useful. It's not complete and I think some of the principles don't align that well to the problem space. The big one: "Data is immutable". The problem here is that data isn't actually immutable (generally) and mutability isn't actually the problem. The problem is unmanaged references or other dependencies on the mutable data. The "source of truth" becomes muddled whi…

You realize data is immutable when you first try to implement history. Mutability is just a hack to save some memory.

I think when you start pulling on that string you eventually end up at event sourcing because once you are keeping comprehensive immutable history of all your changes keeping the mutable record anywhere just starts to look like a liability.

Re: Principles of Data Oriented Programming

#117

Post by ickyforce »

piokoch wrote: post #17

Principle #2 always bothers me. "Model the data part of the entities of your application using generic data structures (mostly maps and arrays)." and example function createAuthorData(firstName, lastName, books) { return {firstName: firstName, lastName: lastName, books: books}; } For a simple, obvious object like "person" it might work, but for a complicated domain object with many other composed objects this starts…

What bothers me more is the lack of a way to ensure that the data is valid. Like always things look great in simple examples where it doesn't matter but fail when it gets tricky.

The main benefit of dedicated, encapsulated types is that they can preserve their invariants. Without that each function operating on "data" has to check that those invariants are kept. It's fine in trivial cases e.g. where this validation boils down to checking if a value is present or not - which might even be supported by the language. But I don't see this working in more complex cases.

In my experience many (most?) bugs are caused by the implementation assuming something incorrect about the shape of the data and I feel like this principle only makes it more likely to happen.

Re: Principles of Data Oriented Programming

#120

Post by vvanders »

joe_the_user wrote: post #106
ummonk wrote: post #96

Earlier quoted context omitted.

I think the principles do basically summarize data oriented programming. Particularly, principle 1 is important since it is the exact opposite of OOP's insistence of encapsulation, and is possibly the biggest reason DOP works so much better than OOP.

Evidence that "DOP works so much better than OOP" is scant imo. The rise and fall of paradigms that present themselves as panaceas is instructive. You have "structured programming", "object oriented programming", "functional programming" and now "data oriented programming". What I'd like to see is paradigms paired with "where this works well" rather than paradigms sold based on "this will solve the software crisis",…

That's because data oriented programming has already succeed on a large scale, you just might not recognize it.

SQL is about as data-oriented as it gets, you have a programming model that's constrained and focused on data layout, structure and performance over being a general purpose language. There's a good article a while back about ECS that I can't find which talks about how most performant ECS start to mirror SQL and other row based data engines.

Post reply on HN