Principles of Data Oriented Programming
blog.klipse.tech
Principles of Data Oriented Programming
1–10 of 139 posts
Re: Principles of Data Oriented Programming
#2simple read. good points. this is very useful in event sourcing or in general for sensitive data where mutability might become an issue(ie. financial transactions). also i think this maps to value object perfectly.
i have implemented ES into few projects and am now writing a ES library, since I think it can be done much simpler than my previous implementations that felt too verbose, and I will take some pointers from this into account.
Re: Principles of Data Oriented Programming
#3simple read. good points. this is very useful in event sourcing or in general for sensitive data where mutability might become an issue(ie. financial transactions). also i think this maps to value object perfectly. i have implemented ES into few projects and am now writing a ES library, since I think it can be done much simpler than my previous implementations that felt too verbose, and I will take some pointers from…
Could you share an example of how to apply the principles of DO in the context of event sourcing?
Re: Principles of Data Oriented Programming
#4Clojure-inspired concepts? An upvote from me, despite the hide-out in other languages :)
Re: Principles of Data Oriented Programming
#5simple read. good points. this is very useful in event sourcing or in general for sensitive data where mutability might become an issue(ie. financial transactions). also i think this maps to value object perfectly. i have implemented ES into few projects and am now writing a ES library, since I think it can be done much simpler than my previous implementations that felt too verbose, and I will take some pointers from…
Could you share an example of how to apply the principles of DO in the context of event sourcing?
A entity component system (ECS) as used by many games would probably fall under DO.
Through I would argue that #5 isn't part of DO. Especially given that e.g. `{ "a" : "b" }` is not necessary a literal but potentially an expression (depending on arbitrary language definition aspects). On the other hand e.g. `vec![ "a" ]` in rust is definitionally not an literal but wrt. to the idea behind principle #5 as good as `[ "a" ]` in JavaScript.
EDIT: Lastly sometimes contexts using something like a builder pattern can be the better way to "not verbose creation" and "data is exploreable in any context".
Re: Principles of Data Oriented Programming
#6Earlier quoted context omitted.
Could you share an example of how to apply the principles of DO in the context of event sourcing?
A entity component system (ECS) as used by many games would probably fall under DO. Through I would argue that #5 isn't part of DO. Especially given that e.g. `{ "a" : "b" }` is not necessary a literal but potentially an expression (depending on arbitrary language definition aspects). On the other hand e.g. `vec![ "a" ]` in rust is definitionally not an literal but wrt. to the idea behind principle #5 as good as `[ "…
What do you mean when you write that `{ "a" : "b" }` is not necessary a literal but potentially an expression?
Re: Principles of Data Oriented Programming
#7Very interesting!
In the context of C++ some of us have been calling these programming/design principles "Value Oriented Design". Some talks on the topic:
- Most Valuable Values (Juan Pedro Bolívar) https://www.youtube.com/watch?v=_oBx_NbLghY
- Squaring the circle, value oriented design in an object oriented system (Juanpe) https://www.youtube.com/watch?v=e2-FRFEx8CA
- Objects vs Values: Value Oriented Programming in an Object Oriented World (Tony van Eerd) https://www.youtube.com/watch?v=2JGH_SWURrI
Re: Principles of Data Oriented Programming
#8Whats the general opinion for using Maps instead of Structs/Simple Objects for the data containers in languages that allow for either?
Re: Principles of Data Oriented Programming
#9> One could argue that the complexity of the system where code and data are mixed is due to a bad design and data an experienced OO developer would have designed a simpler system, leveraging smart design patterns.
Indeed he (or she) would have made use of traits/protocols/categories/whatever, to separate behavior from data, while keeping the design extensible (via polymorphism).
This is something I usually find in OOP critics, too much focus on class driven implementations, without spending too much on the other parts of the toolbox.
Re: Principles of Data Oriented Programming
#10Earlier quoted context omitted.
Could you share an example of how to apply the principles of DO in the context of event sourcing?
A entity component system (ECS) as used by many games would probably fall under DO. Through I would argue that #5 isn't part of DO. Especially given that e.g. `{ "a" : "b" }` is not necessary a literal but potentially an expression (depending on arbitrary language definition aspects). On the other hand e.g. `vec![ "a" ]` in rust is definitionally not an literal but wrt. to the idea behind principle #5 as good as `[ "…
I think DOD of games is only tangentially related to this post.