> At this point I should address the elephant in the room. If we're talking about declared computations with input dependencies and cached results, isn't this what data flow graphs are for? Today DFGs are still only used in certain niches. They are well suited for processing media like video or audio, or for designing shaders and other data processing pipelines. But as a general coding tool, they are barely used. Why?

sidenote: the programming model of Observablehq is a data flow graph and its bloody excellent for hot developing a running program. You can swap one dataflow node for a completely different piece of code and leave the rest of the program state in place. This is finer grain iteration than a REPL.

The topic is reconciliation on top of that... and those kinda of experiments are possible. Observablehq exposes the "this" value to access the previous value of the node. So you can do traditional reconciliation: https://observablehq.com/@tomlarkworthy/reconcile-nanomorph

An individual dataflow at the top level can be seen as a stream of values.

I have not thought much about general reconciliation, but if I were shooting for maximum efficiency I would be thinking about maybe you could add delta sync to these streams.

I definitely observe the situation where I want a dataflow node to be an array of values, or an aggregate result over an array, and then I want to add a single datum to the dataset upstream. Currently everything just gets recomputed from scratch which seems wasteful. I am not sure if generalising reconciliation helps with the issue though.