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

Principles of Data Oriented Programming

blog.klipse.tech

Post reply on HN
Print view View original

51–60 of 139 posts

Re: Principles of Data Oriented Programming

#51

Post by danielscrubs »

pjmlp wrote: post #34
danielscrubs wrote: post #29

Earlier quoted context omitted.

The other parts exist in one form or another in non oop languages too. Heck, polymorphism is part of type theory, traits exists in Ocaml and Haskell... But arguing what and what isn’t oop isn’t that productive as no one will agree to any definition. That’s why you’ll get gut responses about lasagna code where the layering glue is more complex and of bigger proportions than the algorithm itself...

Which is why I find a complete waste of time the whole OOP vs FP vs ECS vs ADT discussions, instead of embracing all ideas as part of multi-paradigm toolbox that most mainstream languages actually are.

To a point I agree, but formal verification is a thing and wouldn’t handle a normal mainstream language as we know it.

Re: Principles of Data Oriented Programming

#52

Post by mumblemumble »

piokoch wrote: post #17

Principle #2 always bothers me. "Model the data part of the entities of your application using generic data structures (mostly maps and arrays)." and example function createAuthorData(firstName, lastName, books) { return {firstName: firstName, lastName: lastName, books: books}; } For a simple, obvious object like "person" it might work, but for a complicated domain object with many other composed objects this starts…

> for a complicated domain object with many other composed objects this starts to be a pain

It may be that complicated domain objects with many other composed objects are not compatible with this style of programming.

Whether or not that's a good thing could be the subject of an interesting discussion. For one thing, negative experiences with the "large complex classes" approach to domain modeling is a major factor in the backlash against object-oriented programming. Lately I've been trying to familiarize myself more with the early literature of OOP, and I'm discovering that even OOP's early pioneers had already had bad experiences with it, and would warn against the temptation to do things that way. OTOH, there's undeniably a certain attractiveness to it, otherwise it wouldn't be so common.

Re: Principles of Data Oriented Programming

#53

Post by andi999 »

acarabott wrote: post #49
andi999 wrote: post #32

Earlier quoted context omitted.

Usually a map can be fine, but isnt it a maintenance nightmare. At least if you change an object, the compiler will complain if an attribute is not found, but this leads to runtime error/ or bad behaviour

Adding a version field can be useful to avoid this. Particularly if your entire state is stored in one object.

Agree. But then every function using the map has to query the versiom field?

Re: Principles of Data Oriented Programming

#54

Post by jayd16 »

piokoch wrote: post #17

Principle #2 always bothers me. "Model the data part of the entities of your application using generic data structures (mostly maps and arrays)." and example function createAuthorData(firstName, lastName, books) { return {firstName: firstName, lastName: lastName, books: books}; } For a simple, obvious object like "person" it might work, but for a complicated domain object with many other composed objects this starts…

You can still make helper methods that get the field data for a person from the Person class if you really want. Its not the end of the world but you lose the benefits when you're operating on a single large object in that style.

The reason you would use this setup is so you have all your data in contiguous arrays you can SIMD through quickly. If you're doing a lot of operations where n is low then its not that useful (and even detrimental) to orient your data array-wise.

Re: Principles of Data Oriented Programming

#55

Post by _0w8t »

The examples from the first article about code reuse demonstrates power of row polymorphism. But in a statically typed language that requires a rather advanced type system that allows to declare explicitly or implicitly that code works for any struct that contains the given fields. In C++ one can use templates, but that trivially leads to unmaintainable code.

Re: Principles of Data Oriented Programming

#56

Post by louthy »

conceptoriented wrote: post #35
shwestrick wrote: post #20

Earlier quoted context omitted.

What do you mean by "functions are supposed to be mutable"? Perhaps you are just pointing out that the output of the function (and therefore the value of the field...?) will change as the input changes? If mathematical tuples are immutable, then surely mathematical functions are immutable as well ;)

Function is a mapping between two sets (of values). This mapping between values is mutable although the values are not.

Functions are a mapping between a domain and a codomain, the mapping absolutely isn’t mutable, the definition of the function is the relationship between the domains.

If I have a function:

    int Add1(int x) => x + 1
I would expect the domain and codomain to be immutable; I would also expect that x+1 to not turn in x/2 randomly also

Re: Principles of Data Oriented Programming

#57

Post by cortexio »

This is stupid. Im only in chapter 1 and there are major flaws.

eg.

function fullName(data) { return data.firstName + " " + data.lastName; }

This somehow suggests that firstname and lastname are always stored under the exact same property names and exact same depth of the object.

In practice this will just result in coders making duplicated functions with different names.

eg: fullNameUsing_firstName_lastName , fullNameFromCustomer , fullNameContactPerson

Re: Principles of Data Oriented Programming

#58

Post by gpderetta »

arximboldi wrote: post #7

Very interesting! In the context of C++ some of us have been calling these programming/design principles "Value Oriented Design". Some talks on the topic: - Most Valuable Values (Juan Pedro Bolívar) https://www.youtube.com/watch?v=_oBx_NbLghY - Squaring the circle, value oriented design in an object oriented system (Juanpe) https://www.youtube.com/watch?v=e2-FRFEx8CA - Objects vs Values: Value Oriented Programming in…

Sean Parent has also written a lot on the topic.

Re: Principles of Data Oriented Programming

#59

Post by Jarwain »

ChicagoDave wrote: post #46

Wouldn’t this be the exact opposite of Domain-driven design and modeling behavior? Isn’t the behavior of a system more critical than its data elements?

Reminds me of the quote: > Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious. -- Fred Brooks, The Mythical Man Month (1975)

I don't think they're inherently contradictory. You can have plain data objects representing the domain, and functions that act on these objects representing the behaviors/actions in the domain. You could include these functions as part of the "class" for these objects, and have them return new instances of the class to maintain immutability.

Re: Principles of Data Oriented Programming

#60

Post by accountLost »

arximboldi wrote: post #7

Very interesting! In the context of C++ some of us have been calling these programming/design principles "Value Oriented Design". Some talks on the topic: - Most Valuable Values (Juan Pedro Bolívar) https://www.youtube.com/watch?v=_oBx_NbLghY - Squaring the circle, value oriented design in an object oriented system (Juanpe) https://www.youtube.com/watch?v=e2-FRFEx8CA - Objects vs Values: Value Oriented Programming in…

See also https://matt.diephouse.com/2018/08/value-oriented-programmin... for a very quick introduction.
Post reply on HN