architectures, worldviews

11 days ago

one of the earliest and most helpful concepts i picked up when using folk is the concept of a Hold!. holds allow for stateful behavior. it’s useful to think about this in the same way you might think about holding something in your hand; if would like to hold something new, you’ll need to let go of what’s in your hand to pick the other thing up.

for as useful a tool that Hold! is, it’s worth recognizing that Folk, at a high-level, aims to be stateless; drawtalking is—by purpose and necessity—far more stateful.

code is an expression of intent; those intents emerge from a broader mental model and a larger worldview. software is ultimately built by people, and it follows that any meaningful software integration must first grapple with this at a level that precedes code: shared tools, language, and understanding. in other words, “getting on the same page.”

for different as folk and drawtalking are from software people use every day, they are software nevertheless, and building on and upon them has all of the typical challenges that come with building software collaboratively (though typical and trivial are not synonyms here, as any project or product manager might tell you.)

people often think about design as designing the thing-in-itself. but a substantial portion of what a designer actually constructs are the artifacts and processes that facilitate shared decision making. do we all understand what we’re trying to solve? do we have a shared mental model of the problem space? and is that foundation clear enough for us to make a decision about how to move forward?

folk and dt emerge from different worldviews; dt is imperative and stateful by design, while folk is reactive and tends toward statelessness. because of this difference, solving the problem of integration is a question of creating a unified mental model of both systems. solutions proposed from within only one system’s logic will necessarily talk past each other. my goal in proposing an architecture between the two was to create an artifact that would allow us to have a meaningful discussion about both halves as a whole.

folk, at its heart, operates like a reactive database; statements relate to and are triggered and/or processed by other statements, and these interactions occur within a global statement space. even holds, which allow for stateful behavior, can be read, accessed, and rewritten by any other claim. there are no “data structures” in the traditional sense when working idiomatically in folk; the entire system can be thought of as being discretized at the level of individual facts or claims.

this stands in tension with drawtalking, which relies on conventional data structures (i.e. a hashmap) in its graphics pipeline. this confers an explicit performance benefit; if all graphics are buffered within a hashmap, only the individual values that require changes need to be updated, rather than recreating the entire structure per-frame.

integration between these two systems would require conceptually remapping a hashmap’s core functional advantages using the idiomatic tools already provided by folk’s database-like structure. by splitting each graphics entity in dt’s buffer into a series of smaller keyed holds (for example, dt152_base for long-lived mesh information and dt152_props for properties updated per frame), we can update only what we need and keep data sent over the wire to a minimum of only what needs to change per frame. because holds are global, we can then use folk’s existing Query! and collection tools to aggregate this information and render it.