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

31–40 of 139 posts

Re: Principles of Data Oriented Programming

#31

Post by OneGuy123 »

In the context of C# this becomes a real pain.

The isuee are arrays/lists.

Because in C# an int[] array or List is a reference.

So even if you put a int[] in a struct this int[] will NOT be copied when you assign an instance of this struct to another instance: you will get a reference share which makes this annoying since you cannot do a proper deep copy with the language itself: you are forced to use reference copy instead of deep copy.

In C++ this is easy because the types differentiate between pointer and non-pointer explicitly + you can overload the assignment operator.

Re: Principles of Data Oriented Programming

#32

Post by andi999 »

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…

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

Re: Principles of Data Oriented Programming

#33

Post by pjmlp »

odshoifsdhfs wrote: post #19
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…

If you use simple data structures without logic, it is basically what he is saying. Basically `createAuthorData` is a data structure constructor. There are some advantages by using _.pick or something in JS land, but these don't work for other more strictly typed languages. Also, I would be careful with using it so much as his example: ``` function createAuthorData(firstName, lastName, books) { return {firstName: fir…

Or when structure typing is available,

    type example = { firstName : string; lastName : string};;
    let name x = x.firstName;;
    name {firstName = "Joe"; lastName = "User"};;
Or to make it more specific

    let name { firstName : string} = firstName;;

Re: Principles of Data Oriented Programming

#34

Post by pjmlp »

danielscrubs wrote: post #29
pjmlp wrote: post #9

> One could argue that the complexity of the system where code and data are mixed is due to a bad design and data an experienced OO developer would have designed a simpler system, leveraging smart design patterns. Indeed he (or she) would have made use of traits/protocols/categories/whatever, to separate behavior from data, while keeping the design extensible (via polymorphism). This is something I usually find in OO…

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.

Re: Principles of Data Oriented Programming

#35

Post by conceptoriented »

shwestrick wrote: post #20
conceptoriented wrote: post #14

> Data never changes, but we have the possibility to create a new version of the data. Well, it depends on what you mean by data. To avoid ambiguity it is better to talk about data values and data objects which have different properties. This can be formalized as follows [1]: o data values are modelled via mathematical tuples – tuples are immutable o data objects are modelled via mathematical functions (one field is…

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.

Re: Principles of Data Oriented Programming

#36

Post by pjmlp »

OneGuy123 wrote: post #31

In the context of C# this becomes a real pain. The isuee are arrays/lists. Because in C# an int[] array or List is a reference. So even if you put a int[] in a struct this int[] will NOT be copied when you assign an instance of this struct to another instance: you will get a reference share which makes this annoying since you cannot do a proper deep copy with the language itself: you are forced to use reference copy…

Unless one uses a struct based array instead.

https://docs.microsoft.com/en-us/dotnet/csharp/programming-g...

https://docs.microsoft.com/en-us/dotnet/api/system.memory-1?...

Re: Principles of Data Oriented Programming

#37

Post by mumblemumble »

This reminds me a bit of some of the ideas that Eric Normand presents in his book, Grokking Simplicity.

Which I'd highly recommend. It's aimed at a less experienced audience, so, as someone who's mid-career, I admit I did skim some sections. But, all-in-all, I enjoyed reading his take on how things should be done.

Re: Principles of Data Oriented Programming

#38

Post by weavejester »

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…

> I am not feeling ready to memorize all the field names, I prefer to have an object with documentation for each field.

Using data doesn't preclude documenting fields, particularly if those fields are assigned a unique name.

For example, in Clojure you'd namespace the keys, so instead of "lastName" one might write :author/last-name instead. This keyword can then be documented or even assigned a type/spec.

(That said, you can't currently assign a docstring to a keyword in Clojure without the use of a third party library, or using a comment or external document. Hopefully a future version of Clojure will make this part of the core language.)

Re: Principles of Data Oriented Programming

#39

Post by hakre »

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…

The author argues DO is in favour to reduce complexity, but also notes on the prices of it and reminds that it's in the eye of the beholder to decide whether or not it is of benefit.

Many of the early PHP applications were written in a style using generic data structures (array that is in PHP) having functions dealing with all these.

There is no free lunch.

If you already have domains you can model in, the strategy to reduce complexity is perhaps more from the DDD book which looks like a higher level concept to me and therefore may be more fitting for higher complexity levels.

(but again, one for sure can shoot in her own foot with DDD as well)

What I like about the DO thing is it maps well on simple REST APIs sending and receiving JSON text. Quite popular these days to say the least if not mentioning Serverless.

A similar trend can also be seen in structural logging.

These systems are often distributed and complex.

As it bothers you in your case, I would tend to say, it's better to stick to a domain if there is one. Across boundaries of domains, values to emit and receive data can work out very well though I can imagine. As so often, it depends.

Re: Principles of Data Oriented Programming

#40

Post by tgb »

What's the solution to referring to other "objects" in this setup? For example, an Author has a list of Books that they wrote. I see several possible ways to do this, but they all seem to have downsides.

1) The author map has a "books" entry that is a list of map containing the book data. But multiple authors might have written the same book, so does the book data get copied there?

2) The author contains a "books" entry that is a list of Book IDs, like foreign keys in a database. But how about immutability? If you want to get the book addressed by the ID, you need to look it up somewhere and are you guaranteed the object you get from the lookup is still the same one as it was earlier?

3) There is a "Author -> Book" map somewhere that you can pass an author and it gives you the list of books they wrote. Not sure about this one.

Post reply on HN