Revisiting the principles of data-oriented programming • Hacker News Board

Re: Revisiting the principles of data-oriented programming

#71

Post by deltaonefour » Sun, Jun 26, 2022, 8:08 AM UTC

danielscrubs wrote: post #56

deltaonefour wrote: post #52

Earlier quoted context omitted.

One way to define it is to look at the thing that's unique to OOP that isn't used in any other paradigm. In OOP data and method are unionized into primitives that form the basic building blocks of your program. This is unique to OOP. It must be the definition. Defining it in terms of message passing, encapsulation and inheritance are not as good because these concepts are used in other paradigms as well.

Wouldn’t closures and let’s say “type-driven” also support your definition? It’s quite tricky as sometuple.fun() and fun(sometuple) might as well be interchangeable. If you really want to support a formal definition it would probably be best to have it in denotational semantics… not an easy task.

Most things in programming aren't formally defined. It is especially hard given the isomorphisms everywhere.

At best what I've done here is eliminate some of the vagueness surrounding the definition, which is really all that's needed in most cases.

Re: Revisiting the principles of data-oriented programming

#72

Post by deltaonefour » Sun, Jun 26, 2022, 8:17 AM UTC

alphanumeric0 wrote: post #11

I'm having a hard time thinking of a way code can ever be fully decoupled from data. When we decide it's better to have a name field rather than firstName and lastName does that mean we simplify NameCalculation.fullName to just return data.name? This seems to suggest we still have coupled code to data (the data structure being an object), it's just now a coupled function, but you have decoupled it enough to use NameC…

If you have a hard time thinking this way then you really need to try other paradigms in coding because OOP is not the only way and it is getting less and less popular.

For example C, is not OOP. Linus Torvalds hates OOP, so linux is in written in C. Go was created by Robert Pike who's also subtly against it, and it shows in the language. Additionally Rust pretty much gets rid of objects as well. React is also moving away from class based representation of components.

These are just modern languages that are moving away from OOP. In addition to this... behind the modern languages there's a whole universe and history of other styles of programming.

Not against OOP... But I'm saying it's not a good sign if OOP is the only perspective you're capable of seeing.

Re: Revisiting the principles of data-oriented programming

#73

Post by deltaonefour » Sun, Jun 26, 2022, 8:20 AM UTC

roenxi wrote: post #44

alphanumeric0 wrote: post #11

I'm having a hard time thinking of a way code can ever be fully decoupled from data. When we decide it's better to have a name field rather than firstName and lastName does that mean we simplify NameCalculation.fullName to just return data.name? This seems to suggest we still have coupled code to data (the data structure being an object), it's just now a coupled function, but you have decoupled it enough to use NameC…

Code is itself data, so a full decoupling is logically impossible. Data is going to have an implicit schema regardless because that is just how data works. And once there is a schema, it may as well be expressed explicitly independently of the code because then you get the whole basket of standard schema operations for free (validate the data against a schema, provide a schema to an external consumer when moving data…

> Code is itself data, so a full decoupling is logically impossible.

Nah, code exists in a different universe then "data" and it's decoupled by default. Runtime data is completely unaware of "code." that is unless you do something called "reflection" which is sort of a rarely used feature.

Re: Revisiting the principles of data-oriented programming

#74

Post by rawoke083600 » Sun, Jun 26, 2022, 8:20 AM UTC

411111111111111 wrote: post #59

yxhuvud wrote: post #57

Earlier quoted context omitted.

Another way to phrase it is to note that the question is answered by the question of what happens when the wand is dropped and the goblin picks up the wand. Can it cast the spell? Then it belongs to the wand. If not then it belongs to the wizard. In this case it just mean you have to match your game semantics to the decision of where to put the ability. That doesn't mean it would be a good idea to perform fighting by…

You haven't convinced me with that at all, honestly. You can also have the spell on the wand and require n mana to be put into it for activation (argument), now warrior type goblins won't be able to use it either. There is no "correct way" with OOP: There are as many ways as you've got the energy to think about and all of them are leaky somewhere . You can still write maintainable code with it, but making it sound cl…

This ! Each answer here as to where to put it is different or breaks down in different scenarios.

While none of the OOP solutions are outright wrong, neither one are "obviously right".

Re: Revisiting the principles of data-oriented programming

#75

Post by zwkrt » Sun, Jun 26, 2022, 8:28 AM UTC

zasdffaa wrote: post #70

yxhuvud wrote: post #57

Earlier quoted context omitted.

Another way to phrase it is to note that the question is answered by the question of what happens when the wand is dropped and the goblin picks up the wand. Can it cast the spell? Then it belongs to the wand. If not then it belongs to the wizard. In this case it just mean you have to match your game semantics to the decision of where to put the ability. That doesn't mean it would be a good idea to perform fighting by…

Multiple dispatch solves that question. I wish it was better known. Dispatch is on both wizard (or generally, user) and wand (or generally, item used)

Right but now it’s also raining and a full moon and the goblin is a werewolf and wands also have AOE spells that hit multiple opponents, except when those opponents are blocking…

Sure, the code kinda sucks either way, but the data oriented approach works exponentially better as the object interactions become more complicated. A “cast” function called as part of the event loop can look up all the game state in the state DB as it needs to. wand.cast(…) is a lot more brittle, ESPECIALLY once one wants to start reusing some of the code in sword.swing(), etc.

Re: Revisiting the principles of data-oriented programming

#76

Post by oivey » Sun, Jun 26, 2022, 8:29 AM UTC

jcelerier wrote: post #68

oivey wrote: post #51

Earlier quoted context omitted.

OO schemas are very strict and in many situations difficult to extend. For example, let's say you have a class named Name that contains firstName and lastName. Let's say that you have a function that consumes lists of Names. Let's say you have yet another class called OtherName that contains firstName and lastName. That class will not be compatible with the function. Usual OOP suggests you solve this via inheritance,…

> OO schemas are very strict I mean, it's the whole point. You want to have something that will give you compile errors whenever you change anything to make sure that you go all over the cases where the change has an impact

The goal of OOP or any programming system is to help you enforce invariants to improve correctness of a program. “has String members ‘firstName’ and ‘lastName’” is a perfectly reasonable invariant that isn’t all that well served by traditional OOP. You can’t strictly enforce the invariant I just stated via OOP. You can only define tangentially related concepts via inheritance.

Re: Revisiting the principles of data-oriented programming

#77

Post by zasdffaa » Sun, Jun 26, 2022, 8:45 AM UTC

zwkrt wrote: post #75

zasdffaa wrote: post #70

Earlier quoted context omitted.

Multiple dispatch solves that question. I wish it was better known. Dispatch is on both wizard (or generally, user) and wand (or generally, item used)

Right but now it’s also raining and a full moon and the goblin is a werewolf and wands also have AOE spells that hit multiple opponents, except when those opponents are blocking… Sure, the code kinda sucks either way, but the data oriented approach works exponentially better as the object interactions become more complicated. A “cast” function called as part of the event loop can look up all the game state in the sta…

> wand.cast(…) is a lot more brittle

That's not how it works. Multiple dispatch looks like a normal procedure call, it would look like

    cast(item, user)

or if you need to know it was raining

    cast(item, user, worldstate)

Re: Revisiting the principles of data-oriented programming

#78

Post by jcelerier » Sun, Jun 26, 2022, 8:57 AM UTC

oivey wrote: post #76

jcelerier wrote: post #68

Earlier quoted context omitted.

> OO schemas are very strict I mean, it's the whole point. You want to have something that will give you compile errors whenever you change anything to make sure that you go all over the cases where the change has an impact

The goal of OOP or any programming system is to help you enforce invariants to improve correctness of a program. “has String members ‘firstName’ and ‘lastName’” is a perfectly reasonable invariant that isn’t all that well served by traditional OOP. You can’t strictly enforce the invariant I just stated via OOP. You can only define tangentially related concepts via inheritance.

> You can’t strictly enforce the invariant I just stated via OOP.

but you can strictly enforce it in pretty much every relevant OOP language - Java, C#, C++, C, Rust, D, ... by defining a class / struct / record with these two members, which is the only thing that matters. No one programs in abstract design principles, only in actual programming languages.

Re: Revisiting the principles of data-oriented programming

#79

Post by agrafix » Sun, Jun 26, 2022, 9:19 AM UTC

bo0O0od wrote: post #32

Awful stuff. These principles could only ever make sense in a dynamic language since it's mostly manually enforcing some of the basic functionality of a type system, but the fact that he also tries to argue this style could be used in a language like C# throws that defense out the window. https://blog.klipse.tech/databook/2022/06/22/generic-data-st... The examples also contradict his other principles, i.e. immutabili…

you can type check this in static languages too if the type system supports structural typing [0]

[0] https://en.wikipedia.org/wiki/Structural_type_system

Re: Revisiting the principles of data-oriented programming

#80

Post by discreteevent » Sun, Jun 26, 2022, 9:35 AM UTC

deltaonefour wrote: post #72

alphanumeric0 wrote: post #11

I'm having a hard time thinking of a way code can ever be fully decoupled from data. When we decide it's better to have a name field rather than firstName and lastName does that mean we simplify NameCalculation.fullName to just return data.name? This seems to suggest we still have coupled code to data (the data structure being an object), it's just now a coupled function, but you have decoupled it enough to use NameC…

If you have a hard time thinking this way then you really need to try other paradigms in coding because OOP is not the only way and it is getting less and less popular. For example C, is not OOP. Linus Torvalds hates OOP, so linux is in written in C. Go was created by Robert Pike who's also subtly against it, and it shows in the language. Additionally Rust pretty much gets rid of objects as well. React is also moving…

I think all of your examples allow encapsulation of data behind polymorphic interfaces. So, not data oriented. This includes the Linux kernel [1]

https://www.cs.cmu.edu/%7Ealdrich/papers/objects-essay.pdf