3 ms·
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 allo
by etbebl 2mo ago
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 2mo agoI 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 2mo agoYes 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 2mo agomarimo 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. ```