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

111–117 of 117 posts

Re: Revisiting the principles of data-oriented programming

#111

Post by jcelerier »

oivey wrote: post #110
jcelerier wrote: post #107

Earlier quoted context omitted.

> The goal of OOP or any programming system is to help you enforce invariants to improve correctness of a program. enforcing invariants means reducing the number of types that satisfy the invariant. I wouldn't call doing what you ask for "enforcing" any invariant. > Bonus: write it for any struct containing firstName and lastName. well, auto concatenate(auto t) { return t.firstName + " " + t.lastName; } satisfies you…

Ahh you’re, right, I forgot about fully auto’d functions. I think want more structure than just auto everything, although the compilers should find mistakes with that. Concepts will be nice.

The concept version here would look like:

    template
    concept WesternishName = requires (T t) { 
      { t.firstName } -> convertible_to; 
      { t.lastName } -> convertible_to;
    };

    auto concatenate(WesternishName auto t) { return t.firstName + " " + t.lastName; }

Re: Revisiting the principles of data-oriented programming

#112

Post by viebel »

jackosdev wrote: post #100
bob1029 wrote: post #85

I believe the easiest way to think about it is to get away from your programming tools and to start modeling your problem domain as tables in excel. Once you have a relational schema that the business can look at and understand, then you go implement it with whatever tools and techniques you see fit. This is what “data-oriented” programming means to me. It’s not some elegant code abstraction. It’s mostly just a proce…

This confused me as when I hear data-orientated I think data structures that are optimised around minimising CPU cache misses by using better alignments, using enums where possible, not storing results of simple calculations etc. There is a popular book and popular talks on the subject. Probably confuses other people as well I'd imagine

DOP is not the same as DOD [1]

1: https://blog.klipse.tech/visualization/2021/02/16/data-relat...

Re: Revisiting the principles of data-oriented programming

#113

Post by viebel »

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…

DOP is a good fit for building information systems

Re: Revisiting the principles of data-oriented programming

#114

Post by jayd16 »

weavejester wrote: post #41
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…

It's not impossible to type check heterogeneous maps at compile time, but most static type systems don't support this. I think you'd certainly see much more friction trying to program like this in C# than you would in Clojure.

C# has type safe anonymous types.

    //Anonymous type with integer property
    var foo = new {Number = 1};
    //Compile time error if you try to assign a the integer property to a string
    string s = foo.Number;
An object is just a fancy map, after all... These are also immutable by default, which probably makes them even more relevant to this DOA discussion.

Re: Revisiting the principles of data-oriented programming

#115

Post by weavejester »

jayd16 wrote: post #114
weavejester wrote: post #41

Earlier quoted context omitted.

It's not impossible to type check heterogeneous maps at compile time, but most static type systems don't support this. I think you'd certainly see much more friction trying to program like this in C# than you would in Clojure.

C# has type safe anonymous types. //Anonymous type with integer property var foo = new {Number = 1}; //Compile time error if you try to assign a the integer property to a string string s = foo.Number; An object is just a fancy map, after all... These are also immutable by default, which probably makes them even more relevant to this DOA discussion.

Maps are open, while objects are closed.

Re: Revisiting the principles of data-oriented programming

#116

Post by theteapot »

weavejester wrote: post #36
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…

Just imagine you're sending the data across a network, instead of between local functions. If you have a web service that spits out JSON, then you have data that is decoupled from code. That's not to say that the JSON data isn't then read and manipulated by code; just that no specific code is associated with the data. As for why you'd want to do this, well, one reason is that it makes it easier to bounce data between…

> Just imagine you're sending the data across a network, instead of between local functions. If you have a web service that spits out JSON, then you have data that is decoupled from code. That's not to say that the JSON data isn't then read and manipulated by code; just that no specific code is associated with the data.

That's not really true in classical OO or DOP. There is always code that depends on specifics of some data. In classical OO it's extremely common to de-marshal data straight off the wire and into a class (AKA hydration). From then on the thing that interacts with the data structure directly is the object instance.

Re: Revisiting the principles of data-oriented programming

#117

Post by theteapot »

treis wrote: post #109
zwkrt wrote: post #75

Earlier quoted context omitted.

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…

>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… >the data oriented approach works exponentially better as the object interactions become more complicated Maybe it's just me, but I still don't see the difference. To use your example, you'd have a function like: cast(caster, targets, weath…

> My mental model of a class is a data structure plus a bunch of functions that implicitly take the data structure as a parameter.

That's not OO. A class without instantiation is just namespacing.

Post reply on HN