[etbebl]

I was interested in marimo, but I became less interested when I realized that they traded off being able to assign to a variable more than once in order to allow out-of-order execution of cells.

I mean as a Jupyter user, I typically do both and just keep track of what I'm doing in my head (like a repl with many snippets I can run any time), but if I wanted to make it more predictable, I would definitely give up out-of-order execution first.

[boron1006]

I think that’s just a fundamental tradeoff though.

Being able to run Jupyter cells independently is a feature until it’s not.

I’d say for most of my one-off work, it’s fine. But for stuff I want to share it’s not.

[etbebl]

Yes I understand it's a tradeoff, but I'm saying I would prefer a different tradeoff. It would be more intuitive to me if running a cell always invalidated the cells below; this would make variable reassignment unambiguous, just like in a script, but still with all the visualization goodies of a notebook.

[cantdutchthis]

marimo dev here.

Just wanted to mention that you're always able to do this:

for _x in range(100): ...

This way, `_x` is detected as a throwaway Python variable. And it won't re-appear in other cells.

Also, within the same cell you can always re-assign. But you can't do that in another cell. We want to ensure that a variable is fully declared in one, and only one, cell.

``` # cell A, totally fine

a = 1 for _ in range(100): a = a + 1

# but don't re-assign a in another cell. ```