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

Revisiting the principles of data-oriented programming

blog.klipse.tech

Post reply on HN
Print view View original

51–60 of 117 posts

Re: Revisiting the principles of data-oriented programming

#51

Post by oivey »

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…

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, but if you don't own Name or OtherName that won't help you. OOP's tools for polymorphism are very limited, especially if you don't own all the code you're trying to use (third party libraries). If the "schema" enforced by the type system didn't include the name of the object that opens up a lot of possibilities.

Re: Revisiting the principles of data-oriented programming

#52

Post by deltaonefour »

throwaway894345 wrote: post #50
g9yuayon wrote: post #48

Reading the discussion here, I can't help but thinking that people are defending their own philosophies: OOP vs FP vs DOP vs etc. I wish the author had killer applications or killer examples in different categories, like can I code an operating system easier, can I code a database easier, can I create a complex streaming job easier, can I write a library as complex as Apache BEAM easier, can I write a compiler easier…

You'll have to define "OOP" first. Everyone thinks its defined, but even among OOP proponents there isn't consensus ("it's about message passing", "it's about encapsulation", "it's about inheritance", "it's about dot-method syntax", etc).

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.

Re: Revisiting the principles of data-oriented programming

#55

Post by eurasiantiger »

sidlls wrote: post #13
irrational wrote: post #9

Earlier quoted context omitted.

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.

People try to use JavaScript for so many things because it's (surface-level) inexpensive, not because it's good at anything.

Mind-reading and zealotry, you must be a priest. What is your denomination?

Re: Revisiting the principles of data-oriented programming

#56

Post by danielscrubs »

deltaonefour wrote: post #52
throwaway894345 wrote: post #50

Earlier quoted context omitted.

You'll have to define "OOP" first. Everyone thinks its defined, but even among OOP proponents there isn't consensus ("it's about message passing", "it's about encapsulation", "it's about inheritance", "it's about dot-method syntax", etc).

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.

Re: Revisiting the principles of data-oriented programming

#57

Post by yxhuvud »

411111111111111 wrote: post #47
treis wrote: post #40

Earlier quoted context omitted.

>But then my wizard casts a spell, and does damage to a goblin. Do we put the cast method on the wand, the wizard? There is no real reason to pick one over the other You did pick: "My wizard casts a spell". The cast method goes on the wizard.

Unless cast is an ability unlocked by the wand, then you'd only have "use main/offhand" on the person, and the cast would be on the wand. It's really not as cut and dry as you said.

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 simple method calls on the objects though. It is very likely one would want to extract the abilities granted by skills and object to a separate entity that change seldom enough.

That doesn't mean I see what problems a schema solves here. That mostly seems like unecessary indirection..

Also note I don't try to refute the problem in general, just this specific example. Maths have lots of examples that doesn't have the semantic baggage that makes the question solvable.

Re: Revisiting the principles of data-oriented programming

#59

Post by 411111111111111 »

yxhuvud wrote: post #57
411111111111111 wrote: post #47

Earlier quoted context omitted.

Unless cast is an ability unlocked by the wand, then you'd only have "use main/offhand" on the person, and the cast would be on the wand. It's really not as cut and dry as you said.

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 clear and obvious where what should go is just wrong. It heavily depends on a multitude of factors and can get nauseatingly complex at times

Re: Revisiting the principles of data-oriented programming

#60

Post by brunooliv »

Truly misguided article as most of the things by the author, unfortunately. I was so excited about the book "Data-oriented programming" when it was first being released...it was so heavily publicized as well that it was constantly in my face which likely pushed me over the edge to give it a shot and buy it.

Unfortunately, not all that glitters is gold. It feels extremely beginner oriented, only touched basic concepts taught at uni level and it shows a huge disconnect between the theory and the real world work of a developer leveraging data in any way, shape or form.

Don't buy the book, it's so not worth it.

Post reply on HN