Thread by @CalebFiggers

@roamhacker @codexeditor IMVHO (that's My Very Humble opinion—I have no credentials in CS or professional experience coding, just amateur self-education) it's very important to distinguish "data structure" from "data model."

Often people SAY the former and seem to MEAN the latter.

@roamhacker @codexeditor I HIGHLY recommend this video about RISC-V from this one YouTuber with a Swiss Accent:

It's colossally insightful, both about chip architecture specifically and structured thinking/processing more broadly.

Below is a highlight from that video:

@roamhacker @codexeditor Andreas makes some observations about the bare concept of a "technology stack."

Tech stacks are valuable because they allow us to decouple implementation from higher-level function.

E.g.: If you use a PC, whether your processor is Intel or AMD shouldn't change your experience.

@roamhacker @codexeditor This next insight from Andreas blew my mind when I first encountered it: in a given stack, Flexibility at one level of a stack REQUIRES Standardization at the next layer down.

He unpacks this very helpfully with examples—again, highly recommend the whole video.

@roamhacker @codexeditor Here's how this applies to the "Data Structure" vs "Data Model" distinction.

We talk about "data structures" like there are lots of them, each with different advantages and trade-offs. And like we can borrow the "data structures" from one context for application to another.

@roamhacker @codexeditor But I'm starting to think that "data structure" should be on the layer BELOW industry/application-specific insight.

"Data Structure" should be standardized. "Data MODEL" should be what encodes the unique way of thinking distinctive to a specific context.

@roamhacker @codexeditor At the end of the day, the purpose of data STRUCTURE is just to map keys to values. A data MODEL tells you how those values are organized. When we make one encoding carry both, we sacrifice both Standardization and Flexibility by conflating two separate layers of the stack.

@roamhacker @codexeditor E.g., the way JSON is often implemented in industry. JSON usually carries BOTH key-value pairs AND a representation of how those values are structured together. This is an anti-pattern because it makes one structure do double duty.

@roamhacker @codexeditor @codexeditor preaches all the time the benefits of standoff annotation for markup—this is that exact concept but applied to data itself and how programs interact with it.

@roamhacker @codexeditor In this conference talk from Clojure Conj 2018, Rich Hickey talks about how Clojure grapples with this in spec (and all the same thinking applies to Datalog/Datomic):

@roamhacker @codexeditor I think Clojure/Datalog/Datomic gets it right—the purest form for data-as-values to take is a really long series of tuples (in Datalog/Datomic's case, a five-value tuple but there's more than one way that this can be done).

@roamhacker @codexeditor Bottom line: If we're sufficiently distinguishing between a) data as the info itself and b) data model as the info's shape, then I'm not sure it makes sense to talk about taking the "Data Structures" from one context to another.

Soapbox rant over, thanks for your patience 😁