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

91–100 of 117 posts

Re: Revisiting the principles of data-oriented programming

#91

Post by zasdffaa »

uryga wrote: post #90
zasdffaa wrote: post #69

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 guess you mean dependent types[1], but if you don't, I'd appreciate an elaboration. If you do mean DTs, how might it look for a hetero collection? [1] If anybody has any good intros to dependent typing in C#, that'd be much appreciated. A web search throws up some pretty intimidating stuff.

while you probably can do this with dependent types, i'd imagine GP means something along the lines of typescript's structural typing, i.e. const post = { id: 123, content: "...", published: true, } // TS infers the type of `post` to be an unnamed "map-ish" type: // { id: number, content: string, published: boolean } JS objects are map-like, and this one is "heterogenous" in that the values are of different types (un…

Thanks! I guess what you are describing looks - from my very limited experience with scala - as a path-dependent type. If I'm right.

I'm actually talking about C# because I'm working in it and I'd like to make some compile-time guarantees if possible. Or at least know how to assure a method that they are getting a list with at least 2 values in it, for example. It may not be worth the effort but it would be nice to know how.

I've got books on DT, idris, and another DT lang, trouble is there's no call for any of this stuff in industry so they get repeatedly pushed to the bottom of the priority stack. Sickening, innit.

Re: Revisiting the principles of data-oriented programming

#93

Post by mattarm »

zasdffaa wrote: post #77
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…

> wand.cast(…) is a lot more brittle That's not how it works. Multiple dispatch looks like a normal procedure call, it would look like cast(item, user) or if you need to know it was raining cast(item, user, worldstate)

…and thus code is no longer sending _a_ message to _an_ object but using argument types to pick which function/procedure to call. The “cast” function is no longer coupled with any single class, so in effect this problem with OOP has been fixed by not using OOP concepts to solve the problem.

Or, as I sometimes think of it, it can be an OOP design if multiple dispatch is actually a set of messages supported by an implicit, singleton, and usually hidden, “multiple dispatch“ object that handles the dispatch logic. You don’t have to write “dispatcher.cast(a, b, c)” but that is because the language provides the syntactic sugar (and often, an efficient implementation).

Re: Revisiting the principles of data-oriented programming

#94

Post by crabmusket »

oivey wrote: post #51
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…

OO schemas are very strict and in many situations difficult to extend. For example, let's say you have a class named Name that contains firstName and lastName. Let's say that you have a function that consumes lists of Names. Let's say you have yet another class called OtherName that contains firstName and lastName. That class will not be compatible with the function. Usual OOP suggests you solve this via inheritance,…

This is the unfortunate side effect of the Javafication of OOP. Smalltalk doesn't have that problem. Neither does TypeScript, but it has taken us this long to start undoing the Javafication process.

Re: Revisiting the principles of data-oriented programming

#95

Post by deltaonefour »

discreteevent wrote: post #80
deltaonefour wrote: post #72

Earlier quoted context omitted.

If you have a hard time thinking this way then you really need to try other paradigms in coding because OOP is not the only way and it is getting less and less popular. For example C, is not OOP. Linus Torvalds hates OOP, so linux is in written in C. Go was created by Robert Pike who's also subtly against it, and it shows in the language. Additionally Rust pretty much gets rid of objects as well. React is also moving…

I think all of your examples allow encapsulation of data behind polymorphic interfaces. So, not data oriented. This includes the Linux kernel [1] https://www.cs.cmu.edu/%7Ealdrich/papers/objects-essay.pdf

Polymorphism and encapsulation are not features exclusive to OOP.

Isomorphisms exist everywhere. You could say nothing is OOP because it compiles into assembly anyway where pretty much all those concepts don't even exist. You can even say all of assembly can decompile into OOP so everything is OOP.

Think about it. If linus torvolds hates OOP. What is it that he hates? You can say, Linus is an idiot and everything is OOP so he's wrong.

Or you can understand what is it about OOP that he hates and understand the delta between my examples and what is traditionally thought of as OOP.

None* of my examples contain a class. That should be a hint, as that syntax is pretty much used in most OOP languages.

*React still contains class based components except the creators now recommend moving away from class based syntax to functional components.

Re: Revisiting the principles of data-oriented programming

#96

Post by uryga »

zasdffaa wrote: post #91
uryga wrote: post #90

Earlier quoted context omitted.

while you probably can do this with dependent types, i'd imagine GP means something along the lines of typescript's structural typing, i.e. const post = { id: 123, content: "...", published: true, } // TS infers the type of `post` to be an unnamed "map-ish" type: // { id: number, content: string, published: boolean } JS objects are map-like, and this one is "heterogenous" in that the values are of different types (un…

Thanks! I guess what you are describing looks - from my very limited experience with scala - as a path-dependent type. If I'm right. I'm actually talking about C# because I'm working in it and I'd like to make some compile-time guarantees if possible. Or at least know how to assure a method that they are getting a list with at least 2 values in it, for example. It may not be worth the effort but it would be nice to k…

i haven't used scala, but from the looks of it, yeah, "path-dependent types" are a narrow subset of full dependent types, intended for stuff like this exact use case :D

there's things you can do to track list length at the type level, but it usually involves putting your data in a special-purpose linked-list thingy: https://docs.idris-lang.org/en/latest/tutorial/typesfuns.htm...

(the `S` and `Z` refer to peano-style natural numbers)

although if you go that way, you can actually get a lot of that without dependent types! here's an example i found of someone doing a similar construction in C#: http://www.javawenti.com/?post=631496

last but not least, in TS you can use the builtin support for arrays as tuples and just do:

  type AtLeastTwo = [_1: T, _2: T, ...rest: T[]]
which looks very nice, but it's pretty much only doable because the type system has specific support for array stuff like this, so not a really general solution.

Re: Revisiting the principles of data-oriented programming

#97

Post by zasdffaa »

mattarm wrote: post #93
zasdffaa wrote: post #77

Earlier quoted context omitted.

> wand.cast(…) is a lot more brittle That's not how it works. Multiple dispatch looks like a normal procedure call, it would look like cast(item, user) or if you need to know it was raining cast(item, user, worldstate)

…and thus code is no longer sending _a_ message to _an_ object but using argument types to pick which function/procedure to call. The “cast” function is no longer coupled with any single class, so in effect this problem with OOP has been fixed by not using OOP concepts to solve the problem. Or, as I sometimes think of it, it can be an OOP design if multiple dispatch is actually a set of messages supported by an impli…

> …and thus code is no longer sending _a_ message to _an_ object but using argument types to pick which function/procedure to call

I dunno. From https://en.wikipedia.org/wiki/Multiple_dispatch

"Multiple dispatch or multimethods is a feature of some programming languages in which a function or method can be dynamically dispatched based on the run-time (dynamic) type or, in the more general case, some other attribute of more than one of its arguments.[1] This is a generalization of single-dispatch polymorphism [...]"

It's just a nicer OOP to me. *shrug* But thanks.

Re: Revisiting the principles of data-oriented programming

#98

Post by jokoon »

crummy wrote: post #92
jokoon wrote: post #89

I love DOP, and I loathe OOP. But when you use a framework that enforces OOP, it's quickly difficult to use DOP.

What languages/frameworks work well with DOP? Functional languages I guess?

Languages:

Python, C, C++. Not java, for example.

Re: Revisiting the principles of data-oriented programming

#99

Post by zasdffaa »

uryga wrote: post #96
zasdffaa wrote: post #91

Earlier quoted context omitted.

Thanks! I guess what you are describing looks - from my very limited experience with scala - as a path-dependent type. If I'm right. I'm actually talking about C# because I'm working in it and I'd like to make some compile-time guarantees if possible. Or at least know how to assure a method that they are getting a list with at least 2 values in it, for example. It may not be worth the effort but it would be nice to k…

i haven't used scala, but from the looks of it, yeah, "path-dependent types" are a narrow subset of full dependent types, intended for stuff like this exact use case :D there's things you can do to track list length at the type level, but it usually involves putting your data in a special-purpose linked-list thingy: https://docs.idris-lang.org/en/latest/tutorial/typesfuns.htm... (the `S` and `Z` refer to peano-style…

Thanks, yeah, did a big search for DT stuff this morning and found this one. The S/Z is the zero/successor. I need to study it. Perhaps closer to what I originally saw was this https://gist.github.com/bradphelan/26c0e84197092620359a (edit: it's not closer. Still worth a peruse though)

I need to sit and read and butt heads with these if I can find the time.

It's so odd there are so few examples of C# DT. The one good one I found a year ago seems to have disappeared. Maybe a conspiracy?

Looking forward to Idrisizing or Agdicating some time!

Re: Revisiting the principles of data-oriented programming

#100

Post by jackosdev »

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
Post reply on HN