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

11–20 of 117 posts

Re: Revisiting the principles of data-oriented programming

#11

Post by alphanumeric0 »

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 NameCalculation in different contexts. Single responsibility classes are already recommended for reuse like this in OO.

Also when it comes to data validation, OO performs all of this validation too and in a much more compact and code-oriented, extensible way. Why would I write a separate schema when the object itself knows what it will accept, what is optional, and what range the values should be in? I'd imagine the schema and code could become incoherent.

Re: Revisiting the principles of data-oriented programming

#12

Post by ArrayBoundCheck »

mtVessel wrote: post #3

There's something called "Data-Oriented Programming" and something else called "Data-Oriented Design". I can never remember which is which. This post changes nothing.

One is ridiculous and uses immutable data. The other is made famous by a guy in a Hawaiin shirt and preforms well. Designer on vacation might help you to remember which is which

Re: Revisiting the principles of data-oriented programming

#13

Post by sidlls »

irrational wrote: post #9
ncmncm wrote: post #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 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.

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

Re: Revisiting the principles of data-oriented programming

#14

Post by Tomis02 »

ArrayBoundCheck wrote: post #12
mtVessel wrote: post #3

There's something called "Data-Oriented Programming" and something else called "Data-Oriented Design". I can never remember which is which. This post changes nothing.

One is ridiculous and uses immutable data. The other is made famous by a guy in a Hawaiin shirt and preforms well. Designer on vacation might help you to remember which is which

Indeed. The guy in Hawaiian shirt writes simple, fast code with the minimum amount of abstractions, and therefore can afford to finish work early and go to the beach. Everyone else is working overtimes untangling a mess of objects, principles and hierarchies.

Re: Revisiting the principles of data-oriented programming

#15

Post by mistrial9 »

Tomis02 wrote: post #14
ArrayBoundCheck wrote: post #12

Earlier quoted context omitted.

One is ridiculous and uses immutable data. The other is made famous by a guy in a Hawaiin shirt and preforms well. Designer on vacation might help you to remember which is which

Indeed. The guy in Hawaiian shirt writes simple, fast code with the minimum amount of abstractions, and therefore can afford to finish work early and go to the beach. Everyone else is working overtimes untangling a mess of objects, principles and hierarchies.

Larry Wall is that you!?

Re: Revisiting the principles of data-oriented programming

#16

Post by drpyser22 »

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…

For validation, this approach would have you write a set of functions to validate the properties of the data.

Nothing forbids a function that applies validation to inputs before returning a data object? Extensibility can be done through functional means(e.g. higher order functions, function composition, lens) or oop(strategy pattern and equivalents, code object composition and inheritance,...). Not sure what you mean by more compact and code-oriented?

Code is always coupled to an interface, implicitly or explicitly. In the case of oop, code is coupled to the class, which can represent something specific with very concrete semantics (e.g. employee, author) or something generic that is meant to be subclassed(e.g. person).

Re: Revisiting the principles of data-oriented programming

#17

Post by hinkley »

osigurdson wrote: post #10
xixixao wrote: post #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.

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.

That's not necessary either. What we're talking about here is an analog for the real problem, which is "when using an object oriented language, write pure functions even though the language doesn't make you do it".

Static functions introduce friction against making impure functions, but not an overwhelming amount of it. If it's all you have, then there are worse safety blankets, but it's not going to solve your lack of buy-in problem. If everyone is on board then you don't need static functions. If they aren't, static functions aren't going to save you, they're just going to extend the amount of time you suffer before you wise up and get a new job somewhere else.

Re: Revisiting the principles of data-oriented programming

#19

Post by snidane »

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…

> Why would I write a separate schema when the object itself knows what it will accept, what is optional, and what range the values should be in?

Because data is just data and the meaning to it is given at the time of application. If you want to couple validation to the data itself - how do you decide which N of the meanings to validate against?

Re: Revisiting the principles of data-oriented programming

#20

Post by hinkley »

ncmncm wrote: post #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 ther…

I wonder if Alan Kay would agree or argue with this sentiment, but it seems to me that the choice of 'oriented' was intentional and that we've consistently fucked it up ever since then.

Orientation should have been 'a preference for' not 'a dogmatic adherence to'. A hot-dog based diet still contains bread, ketchup, mustard and pickles, possibly some sort of cheese. A hot dog diet is just hot dogs, which is much, much less interesting, and there is no question that it is unhealthy, whereas the former might have some plausible deniability (especially if you add beans).

Post reply on HN