Revisiting the principles of data-oriented programming
blog.klipse.tech
Revisiting the principles of data-oriented programming
1–10 of 117 posts
Re: Revisiting the principles of data-oriented programming
#2I haven't loved debugging systems whose primary data structure is a Map.
Re: Revisiting the principles of data-oriented programming
#3There's something called "Data-Oriented Programming" and something else called "Data-Oriented Design". I can never remember which is which. This post changes nothing.
Re: Revisiting the principles of data-oriented programming
#4Two concepts that seem entirely missing are "ownership" and "transformation". The root of ownership is "system of record" with intermediate systems combining data and doing transformation. "Getting data" becomes a question of where, in a differentiating tree that has it's root in the SoR, you connect to, and the trade-offs that implies.
This post (and the book it points to) is perhaps teaching a new generation what has been known for a long time: the "body" of your business is the data, not the code. E.g. if you have limited space on a thumbdrive and can only keep one thing in a datacenter fire, your database or your codebase, you keep the database.
Re: Revisiting the principles of data-oriented programming
#5"Anything"-oriented programming is dumb. Every big problem is a collection of smaller, different problems. Different problems call for different approaches. Sometimes the best approach has data-oriented features, sometimes object, sometimes functional, sometimes piped. For big problems you want a language good at all of them.
It is why C++ continues to grow. Some complain about that, but every single feature got there over fierce opposition by making some common programming problem more tractable.
Re: Revisiting the principles of data-oriented programming
#6I haven't loved debugging systems whose primary data structure is a Map.
I think it very much depends on what problems you're trying to solve and whether or not proper data types have been defined.
If your primary data structure is
Map>
On the other hand, if your primary data structure is
Map>
Re: Revisiting the principles of data-oriented programming
#7There's something called "Data-Oriented Programming" and something else called "Data-Oriented Design". I can never remember which is which. This post changes nothing.
I think the abbreviated forms of the paradigm are often more "stable" than the full names, because people keep hand-waving the names and thus mixing them up. For me, "DOD" is the thing where you are very performance-oriented and you have flat, cache friendly arrays of data and affinity to ECS (entity-component-system) stuff etc. This is clearly not it, but eyeballing it, the ideas seem somewhat compatible with it. (Except the immutability part.)
Re: Revisiting the principles of data-oriented programming
#8> Adherence to this principle in OOP means aggregating the code as methods of a static class.
This is not OOP, this is a way to do functional programming in a class-based language that lacks top-level function declarations / modules.
While this might seem a nit pick it makes me sceptical about the rest of the content.
Re: Revisiting the principles of data-oriented programming
#9"Anything"-oriented programming is dumb. Every big problem is a collection of smaller, different problems. Different problems call for different approaches. Sometimes the best approach has data-oriented features, sometimes object, sometimes functional, sometimes piped. For big problems you want a language good at all of them. It is why C++ continues to grow. Some complain about that, but every single feature got ther…
I think this is also a reason people try to use JavaScript for so many things. As a multi-paradigm language you can do OOP, functional, etc. in it.
Re: Revisiting the principles of data-oriented programming
#10> Adherence to this principle in OOP means aggregating the code as methods of a static class. This is not OOP, this is a way to do functional programming in a class-based language that lacks top-level function declarations / modules. While this might seem a nit pick it makes me sceptical about the rest of the content.
I think possibly what they meant is "when using an object oriented language like Java or C#", aggregate the code as methods of a static class.