I enjoyed the article. We are doing a more genAI-oriented notebook env variant for louie.ai aimed at database/API users preferring natural-language-first vs typical Jupyter/observable/hex/etc python wrappers, and for their automatic reactivity portion, a lot of similarity here with the road we went down. I appreciate seeing some of that reasoning laid out. Especially neat is the use of static analysis of global assignments vs the typical input/output variable syntactic convention. Few go so fine-grained (enso, frp, ...).
My personal experiences with automatic reactivity (OSS'ing the first web frp system, and many after) and last 10 years as a heavy Jupyter notebooks user with many enterprise/gov/tech DS+operational teams actually steered us down a different path. We separate out the auto-reactivity to only auto-trigger when switched into a 'live' dashboarding view. By default, when in the authoring notebook view, we stick to Jupyter-style manually triggered run / runall. When authoring, the notebook accidently running a bunch of database or OpenAI or bigquery calls when you didn't intend can be... problematic. The underlying cell-based reactivity model we went with is largely the same, but when an analyst is dealing with big database calls and returns, a world of a difference in UX.
Fwiw, if anyone uses Splunk/databricks/OpenSearch/etc and curious about a team genAI-first learning system with auto-viz-reactivity, would love to chat!
As others have mentioned, we're very open about our inspiration and document it in many places, such as on GitHub, though you're totally right that we could have mentioned it here too.
We could fill another blog post talking about inspiration and lessons learned from other projects — perhaps we will!
I think Pluto also lets you reassign a variable.