[graypegg]

Interesting concept! It does remind me of the observables somewhat, where nodes are functions, which accept data coming in from events, which it transforms, and then chooses to emit new values or not.

This flips that, so nodes are data, which accept functions from events, it applies that function to itself, then decides to propagate that event onwards or not.

I like it! That model works really well for this sort of visual programming demoed in the infinite canvas stuff.

[chatmasta]

I only glanced at the article, but it also reminds me of Dataflow programming, incrementally updated materialized views, etc. (all the same concept at the end of the day, and yes, very similar to observables)

[davexunit]

As Gerald Sussman says in "We really don't know how to compute!":

> It's not dataflow! It's closely related, but it's not.

https://youtu.be/HB5TrK7A4pI?t=2071

[CyberDildonics]

It remind you of dataflow programming because it's literally the same thing.

[thechao]

Specifically, the application of dataflow to GUIs, which was well-researched at Adobe by Sean Parent, Mat Marcus, et al in the early 2000s called the "Adam" and "Eve" languages. There's more work at TAMU & University of Turku (by Jaakko Jarvi) under the name "Espresso", or something like that.

Basically, the "scopes" become constraints, and they use a hierarchical constraint solver to propagate state changes to the GUI elements, real-time, using a declarative dataflow programming model.

[CyberDildonics]

Why would it be good when a node is data, since the data is always changing and the function would stay the same?

[graypegg]

    the Scoped Propagator model is based on two key insights:
    1. by representing computation as mappings between nodes along edges, you do not need to know at design-time what node types exist.
    2. by scoping the propagation to events, you can augment nodes with interactive behaviour suitable for the environment in which SPs have been embedded.

It's pretty specific to UI similar to the examples, but in terms of these big infinite canvas UIs, you have a whole bunch of objects you need to make dependant on each other, but who ALSO hold their current state statically. Subtly different from a spreadsheet, where Excel for example treats functions (=$A$2) differently from a single value (4). Functions are always derived, where as single values don't rely on anything.

Like a sticky note on a canvas, should always be available to type into. But maybe we also want something else to change it's value when it changes. (key insights #2, this is for infinite canvases)

Rather than building some big god-object that stores all "root" state for the static value of things, and transforming that thru a big tree of functions you need to keep maintained, you could reverse it:

Each node only knows it's own state, but it's peers give it instructions about how to update itself to meet their business rules, for just that pairing.

The result is the same, it's a big web of functions, but now you don't have to make the distinction between "derived" state or "base" state. It's always static state, and things are just updated adhoc by these events that describe the changes without explaining "why" the "to" node has to apply them. (key insights #1, you do not need to know at design-time what node types exist.)

[CyberDildonics]

So you're talking about a spreadsheet but without the organization of having cells in a grid?