Clojurians Log v2

Hey 👋 Interesting article, the bit about flutter's async got me thinking: Async computations should be denoted and be treated specially. Also propagating "loading" value from async computations is done manually (i.e set loading | set data, if loading do this if data do that). What if the computations graph by default will behave asyncly and automate "loading" propagation? I know the "traditional" dataflow supposed to work that way: expression should wait patiently for their variables to be bound. On the DX side: It'll abstract away actual async computations behind a unified interface where you can choose when and where to address a "loading" state. On the practical side: Not sure what effect the overhead of managing async lifecycle on the computation graph will have but your article and flutter gave me the feeling it should be ok.

Also I thought about the future interface: There are many implementations of working asyncly: (future, stream, promise, channels...) It seems usful to support all kind of implementations by using some common & essensial interface and adapters for each implementation. This will support a veriaty of "sources" from the reactive graph.

"Async computations should be denoted and be treated specially." An important distiction is that async does not need to be treated specially, except that one core design principle of MX is that it be slick to code! "slick" in this case because we avoid the boilerplate of a second input cell just to receive the deferred computations. In other cases "slick" is transparemt subscription and notification. Anyway, if we compare the ai/advance-text and ai/advanced-text-stream examples, we see in the first case how the stream can be handled with a vanilla formula and watch combined with an input. The deeper insight I missed for a long time is that MX has always been about async: the graceful handling of new state by a complex, interdependent model, whenever it arrives.

"Not sure what effect the overhead of managing async lifecycle on the computation graph will have but your article and flutter gave me the feeling it should be ok." Not sure what overhead is of concern, but it seems to me the Flutter choice is to go async on anything that takes more than a millisecond, the idea being better performance by, in effect, parallelizing everything. The only slowdown is the poor developer having to code around async, but MX solves that! 🎉