3 ms·
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 c
by mumblemumble 6y ago
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 https://github.com/palatable/lambda#hlist
[2] https://github.com/typelevel/frameless 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.
- adamnemecek 6y agoNone 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.
- skohan 6y agoEven with this type of design, it's possible to implement in a typesafe way. I have seen clever ECS systems accomplish this
- adamnemecek 6y agoMaybe but ECS does in some sense circumvent types.
- hansvm 6y agoIn some sense. You could build a type system around "has a <foo>" relationships instead of "is a <foo>" and get something pretty cohesive out that closely aligns with ECS.
- mumblemumble 6y agoThat 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.
- fauigerzigerk 6y agoI think a TypeScript style structural type system could work.
- meheleventyone 6y agoBe careful because there are perf issues if you are using parametric polymorphism. Monomorphic functions are preferable but the real problems occur once you get past the inline cache's maximum number of 'shapes'. This obviously applies to regular JS as well.
- fauigerzigerk 6y agoPerhaps I misunderstand, but wouldn't that only apply if you attach functions to objects? I suppose you wouldn't do that if you follow data oriented programming principles.
- meheleventyone 6y agoNope. It's about the different types passed into a function parameter. For optimization JS engines look at the differing shapes of JS objects. Which is determined by the order and type of each member. So: { a: 6, b: 7 } is different to { b: 7, a: 6 } and { a: "six", b: "seven" } is different to both. This is done so the member can be looked up quickly by offset. Functions then have an inline cache that stores the shapes the function has seen. If the function is called monomorphically it will only ever see one shape and hit the fastest path. If it is called with up to three shapes (in V8) it will be pretty quick. Once past three the cache falls through to a global table and is dog slow. This matters if you are using structural typing as you are still creating different shapes to be passed into the same function(s).
- fauigerzigerk 6y agoI see. Thanks for explaining. That's very good to know!