Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Incremental – A library for incremental computations

github.com

Post reply on HN
Print view View original

31–40 of 83 posts

Re: Incremental – A library for incremental computations

#31

Post by valzam »

ronfriedhaber wrote: post #24

This is cool. As far as I can tell, incremental the library aims to solve the problem of partially hydrating a computation graph when source data is altered. This approach is similar to the one pursued by (well designed) build systems and is common in the FP world. [2] This has many use cases and is very cool. In addition, in the sphere of incremental computation, there exists Differential Dataflow, Timely Dataflow (…

> https://modolap.com

Redirect to a 2k USD stripe payment with no explanation when clicking on the main callout button is a pretty baller move.

Re: Incremental – A library for incremental computations

#32

Post by Eliah_Lakhin »

geysersam wrote: post #23
Eliah_Lakhin wrote: post #12

Earlier quoted context omitted.

It depends on how you define the observable pattern. The fundamental components here are laziness and weak connections between graph nodes. Node values are getting materialized only when you observe them, and the system is flexible for live structural changes. Usually, you don't need to materialize the entire graph when you need to observe just some nodes. Additionally, you can halt computations at any point in time…

What does weak connections mean in this context?

I meant that the graph (DAG) structure is not necessary need to be sealed and defined upfront. It could be computed and changed on the fly by the same function that computes node's value. Assuming that the node value computation function is a pure function without side effects (e.g. it's output depends purely on inputs) the function may read other node values directly, and the act of reading would establish graph edges transparently for the user. The next time compute function is being invoked it could re-subscribe on the different nodes hence changing graph structure on the fly. The user also can remove or add new nodes in between of the node values materialization. In other words, the act of subscription between nodes in the incremental computation system is typically tracked more transparently for the user than in the system with explicit observer-subscriber primitives. Even though, this is implementation dependent. The observable pattern could be designed transparently too. Perhaps, "flexibility" would be better term.

Re: Incremental – A library for incremental computations

#34

Post by ronfriedhaber »

valzam wrote: post #31
ronfriedhaber wrote: post #24

This is cool. As far as I can tell, incremental the library aims to solve the problem of partially hydrating a computation graph when source data is altered. This approach is similar to the one pursued by (well designed) build systems and is common in the FP world. [2] This has many use cases and is very cool. In addition, in the sphere of incremental computation, there exists Differential Dataflow, Timely Dataflow (…

> https://modolap.com Redirect to a 2k USD stripe payment with no explanation when clicking on the main callout button is a pretty baller move.

One man's baller is another man's insufficiently baller.

Email me for details, pricing & installations, or your target use case, would love to talk. In addition, if you have any feedback.

ron at modolap dot com

Re: Incremental – A library for incremental computations

#35

Post by iamwil »

RandomBK wrote: post #4

One thing I've never fully grokked is how this differs from an observable pattern where one can publish new values to inputs, propagate that through the computation, and push newly computed values to listeners. I guess there's probably optimizations around change detection and stopping the propagation if there's no change (though observables can do that as well). The stabilize command also makes things interesting as…

https://www.scattered-thoughts.net/writing/an-opinionated-ma...

Can help map out the landscape.

Re: Incremental – A library for incremental computations

#37

Post by evomassiny »

Can't you solve it using hash trees (or Merkle trees) ?

You tag each computation nodes with a hash of its dependencies and some constant salt, that gives you an ID which identifies the results that the computation node would produce; before running it.

You can then use those IDs to index the computations results in a cache; whenever you query a computation results, as long as you update the IDs of each leaf of the computation graph, you will only re-compute the nodes that need to be updated

Re: Incremental – A library for incremental computations

#39

Post by [deleted] »

evomassiny wrote: post #37

Can't you solve it using hash trees (or Merkle trees) ? You tag each computation nodes with a hash of its dependencies and some constant salt, that gives you an ID which identifies the results that the computation node would produce; before running it. You can then use those IDs to index the computations results in a cache; whenever you query a computation results, as long as you update the IDs of each leaf of the co…

[deleted]
Post reply on HN