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

61–70 of 139 posts

Re: Principles of Data Oriented Programming

#61

Post by arximboldi »

gpderetta wrote: post #58
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.

Yes! Also the book Elements of Programming by Stepanov has a lot of "value orientation" in it.

Re: Principles of Data Oriented Programming

#62

Post by hjntmp »

We should rename object oriented programing to bureaucrat oriented programming. I always think that the reasoning that led to develop the aberration of OO is the same that creates bureaucratic nonsense.The want of making people replaceable through bureaucracy so that the programmer as a human being can be removed from the picture plus all the other bureaucratic thinking nonsense leaked to the design of the language. Its funy how ridiculous we are, pretending something all the tme.

Re: Principles of Data Oriented Programming

#63

Post by mumblemumble »

To principle #2:

The author acknowledges this as being incompatible with static typing, but I'm not so sure. Is it that, or is it that it's incompatible with contemporary static languages?

In FP, we already have a concept of type-safe hetergeneous lists and maps, and even some clever implementations in languages like Java[1]. The ergonomics are often less-than-stellar, but I'm pretty sure that's something a new language could fix with some syntactic sugar.

There is also the data frame abstraction (like, you see in Pandas), which is typically implemented on top of dynamic typing, but major implementations often rely on static typing behind the scenes to achieve efficiency. There are also projects like Frameless[2], which implements a statically typed interface over a dynamically typed dataframe package.[3] I'm guessing, again, that careful language design could get us something similar, but with better ergonomics.

And I'd be happy with that. I've been pulling away from static languages lately, and a big part of that is that I really like how some of the dynamic languages let me model my data as data. It's enough of a complexity saver to feel like a net win, even at the cost of some performance and static verification.

[1] For example: https://github.com/palatable/lambda#hlist

[2] https://github.com/typelevel/frameless

[3] Which is itself, notably, implemented in a static language. Spark also has a statically typed version of the API, but its usage is not recommended for several reasons, one of which is performance. That's something that all us static typing fans should really stop to think about for a bit.

Re: Principles of Data Oriented Programming

#64

Post by adamnemecek »

mumblemumble wrote: post #63

To principle #2: The author acknowledges this as being incompatible with static typing, but I'm not so sure. Is it that, or is it that it's incompatible with contemporary static languages? In FP, we already have a concept of type-safe hetergeneous lists and maps, and even some clever implementations in languages like Java[1]. The ergonomics are often less-than-stellar, but I'm pretty sure that's something a new langu…

None of these really apply in this case. In data oriented programming, the data would not be stored in heterogenous lists but each element would be stored in a different, homogenous array and you would ties these together using the same entity ID.

Re: Principles of Data Oriented Programming

#65

Post by discreteevent »

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…

Alan Kay and Rich Hickey discuss the merits of data vs data with interpeters:

https://news.ycombinator.com/item?id=11945722

Re: Principles of Data Oriented Programming

#66

Post by skohan »

adamnemecek wrote: post #64
mumblemumble wrote: post #63

To principle #2: The author acknowledges this as being incompatible with static typing, but I'm not so sure. Is it that, or is it that it's incompatible with contemporary static languages? In FP, we already have a concept of type-safe hetergeneous lists and maps, and even some clever implementations in languages like Java[1]. The ergonomics are often less-than-stellar, but I'm pretty sure that's something a new langu…

None of these really apply in this case. In data oriented programming, the data would not be stored in heterogenous lists but each element would be stored in a different, homogenous array and you would ties these together using the same entity ID.

Even with this type of design, it's possible to implement in a typesafe way. I have seen clever ECS systems accomplish this

Re: Principles of Data Oriented Programming

#67

Post by mumblemumble »

adamnemecek wrote: post #64
mumblemumble wrote: post #63

To principle #2: The author acknowledges this as being incompatible with static typing, but I'm not so sure. Is it that, or is it that it's incompatible with contemporary static languages? In FP, we already have a concept of type-safe hetergeneous lists and maps, and even some clever implementations in languages like Java[1]. The ergonomics are often less-than-stellar, but I'm pretty sure that's something a new langu…

None of these really apply in this case. In data oriented programming, the data would not be stored in heterogenous lists but each element would be stored in a different, homogenous array and you would ties these together using the same entity ID.

That is not quite what the article is talking about.

There's a bit of a terminology collision here. What the article is talking about is not Data-Oriented Design, the practice of organizing your data for efficient processing. It's proposing a separate (but not incompatible) concept of organizing your code for easier maintainability. For example, the sample code (which appears to be JavaScript) is not doing ECS at all. It's almost exclusively doing the data modeling by creating one heterogeneous map per entity.

Re: Principles of Data Oriented Programming

#68

Post by discreteevent »

Joker_vD wrote: post #23

You know, sometimes I wish the programming languages had a better distinction between "immutable data pieces" and "stateful agents". Sometimes it's really nice to have a simple struct for which you (or anyone else) can write many function to act upon. Sometimes it's really nice to have an opaque "object" with methods to yank described in some public interface, but which encapsulates loads of state and other objects i…

The "stateful agents" is what OOP is all about. The objects are interpreters. I referenced a discussion elsewhere in this thread between Alan Kay and Rich Hickey where Kay talks about the value of interpreters. Rich Hickey talks about data/values coming from a seismometer or an IoT device but what he misses there I think is that it's not all just "data". There are also stateful agents. The seismometer (or the earthquake) is a stateful agent and the data is messages that are sent by it. If we had to model a seismometer or iot device (e.g. a smoke alarm) it would be best to do so using an object that encapsulates it's state and manages itself. It only communicates to the outside world with messages/data (in this case a sound when the temperature exceeds some internal state). I can replace my smoke alarm with another and I don't need to understand anything about its internal data or how it interprets it.

But for dealing with the historical data from an IoT device it may make sense to use a data oriented/functional approach. That time series data is not stateful, it's an immutable history of something stateful. Functions/transformations work best there usually.

Re: Principles of Data Oriented Programming

#69

Post by mumblemumble »

viebel wrote: post #50
mumblemumble wrote: post #37

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.

I know that there some common topics with Eric's books. Do you think Eric focuses as much as I do about data?

No, he's much more focused on what he calls actions and calculations.

Perhaps overly so. I'd have liked a bit more focus on data. That could be a by-product of his Clojurist roots. Data-oriented programming is so integral to Clojure's culture that I'm not sure Clojurists even realize they're doing it half the time.

Re: Principles of Data Oriented Programming

#70

Post by fauigerzigerk »

mumblemumble wrote: post #63

To principle #2: The author acknowledges this as being incompatible with static typing, but I'm not so sure. Is it that, or is it that it's incompatible with contemporary static languages? In FP, we already have a concept of type-safe hetergeneous lists and maps, and even some clever implementations in languages like Java[1]. The ergonomics are often less-than-stellar, but I'm pretty sure that's something a new langu…

I think a TypeScript style structural type system could work.
Post reply on HN