Reactive programming is powerful, but often overlooked due to obscure syntax. Given int x,y,z; we can write z=x+y for immediate assignment. What if we could also write z~=x+y to ensure z is recalculated formulaically whenever x or y change, plus when(z) {..} to monitor changes?
-
-
Replying to @TimSweeneyEpic
Probably fine in a language that handles value changes over time rigorously rather than as arbitrary side effects but it seems like a death trap for imperative programming; it'd still be useful in that setting too, but you'd want it to stand out and be applied very carefully.
1 reply 0 retweets 4 likes -
Replying to @pervognsen @TimSweeneyEpic
I think one thing we've learned over the past few decades is that even single-threaded event-driven/callback-driven/asynchronous programming is almost as hard to reason about as general concurrency problems and should be avoided whenever possible.
3 replies 0 retweets 10 likes -
Replying to @pervognsen
Perhaps this only looks like data-race-prone callbacks because of loose legacy practices. What if we were writing straightforward constraint equations, such as between a table’s overall widths, column widths, and column width percentages, and the system magically synced them?
2 replies 0 retweets 5 likes -
Replying to @TimSweeneyEpic
I think auto-updated value expressions/dataflow programming is a great idea. The tension is at the boundaries between the dataflow world and the anything-goes imperative world (your 'when' statement for value-change event handlers).
1 reply 0 retweets 4 likes -
Replying to @pervognsen @TimSweeneyEpic
Actually, not just 'when' statements but anything that can occur in a dataflow value expression that isn't "reactively referentially transparent" i.e. depends on or affects things outside the otherwise simple dataflow world.
2 replies 0 retweets 1 like -
Replying to @pervognsen @TimSweeneyEpic
Incidentally, one example of something along these lines that helps tame the practical issues (without removing them entirely) is forcing all of dataflow evaluation/recomputation to occur at a relatively quiescent program point such as the top-level game loop/run loop.
1 reply 0 retweets 1 like -
Replying to @pervognsen @TimSweeneyEpic
So each frame becomes a synchronous checkpoint for any dataflow state invariants and it lets you have dataflow value expressions depend on imperative non-dataflow state without complete chaos.
1 reply 0 retweets 0 likes -
Replying to @pervognsen @TimSweeneyEpic
It creates up to one frame of lag between the dataflow and non-dataflow world but I think it's worth it for sanity it imposes.
2 replies 0 retweets 3 likes
Interesting. The other extreme is that relational (reevaluable) assignments must be pure, and their work is done lazyily but upon any access after dependencies have changed. So you can never observe an inconsistency in relations.
-
-
Replying to @TimSweeneyEpic @pervognsen
the feature could be done relatively safely when the dependencies are limited to function scope, but it would be helpful to see use cases that would benefit from this ... and, in the end i don't see the big difference between z~=x+y and an invalidable memoized closure z()=x+y
1 reply 0 retweets 1 like -
if limited to function scope, it could be supported as a compile time solution that produces no overhead.
0 replies 0 retweets 1 like
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.