But doesn't marimo force certain workflows that jupyter does not? For example its website states that "Notebooks are executed in a deterministic order, with no hidden state — delete a cell and marimo deletes its variables while updating affected cells." This appeals to people doing traditional software development work in notebooks, but it breaks workflows where people use notebooks as notebooks, where state is entirely separate from the in-notebook presentation of cells. Do people using notebooks these days hate this fundamental feature of notebooks? It's the key reason why notebooks aren't just a transcript of a REPL session!
Anyone trying to reproduce the results in a shared notebook certainly hates that "feature"
Not at all. Its just a development choice. Personally Id stick with Jupyter because state is maintained.
> Do people using notebooks these days hate this fundamental feature of notebooks?
It's one of the things that is the most confusing to people I've worked with. The idea that there is hidden state and you have to re-run cells to get variables to update (or variables still exist when you've deleted those cells) is quite confusing.
If you're trying to have a reproducible workflow, it can be difficult. Jupyter is no different from other notebooks in this regard (RStudio, for example will happily run code and keep variables around that you don't reference any longer in your .R or .Rmd files.)
But I see your point -- if you're using it as a long-term storage notebook, then this is the expected behavior. And you absolutely want to have "historical" data/results kept.
I generally think of / use notebooks as a way to make reports for analyses. So, I want to work with them, draft them, change them, put them in git, etc... then run them all at once to get my output. For me, having a reproducible, documented workflow is more important. I don't want state to be kept outside of those one-off runs. Really until your comment, I didn't understand the other side of the issue, so thanks!