Chaotic/intransparent execution order: Marimo creates NEW Problems normal notebooks do not have

[Julian-J-S]

Let me preface this by saying that overall I really like marimo ❤️

However, having worked with it a lot but also normal Jupyter notebooks and lots of Databricks notebooks I actually have a rather big problem with order of execution which is supposed to be marimo's strength.

Marimo hat lots of benefits compared to standard notebooks which I will not bringt up here but focus on the "problem" I see.

Order of Execution Importance

When running any kind of notebook (DE/DS/DA/ML) in production for example on databricks having a clearly defined order (for the USER) is extremely important.
I want to look at a notebook/code and understand the order of execution.
When checking jobs from the past that were successful or failed I want to know in what order their ran.

Also a lot of times you do sanity checks and if they fail you want to stop execution of the notebook (e.g. in Databricks dbutils.notebook.exit("value to high")). Everything after/below should not run!

Normal Notebook VS Marimo

Normal Notebook:

• on success:
  • easy to understand and visually see: top to bottom
• on failure
  • easy to understand what ran and what not
  • above failure: ran
  • below failure: did NOT run

Example

Marimo

• on success:
  • hard to follow if not using the marimo dependency view
• on failure
  • hard to tell since we cannot rely on the notebook order

Example

My Wish: Top-To-Bottom mode (with reactivity)

I really wish marimo had a "top-to-bottom" mode that:

• runs cells from top to bottom
• stops on errors
• still reactive
• marks "invalid" cells (incorrect order)

[akshayka]

@Julian-J-S — this is interesting. Thank you for sharing in such detail. I don't have a solution off the top of my head, but perhaps there is something we can do; will think about it.

[Julian-J-S]

@akshayka you are welcome 😉
I can always provide more details and feedback if you need. I have written, managed, seen maaaaany notebooks.

Though I love many things about marimo, I cannot use it for production because in my personal option the "flaw" with the execution order is too big and requires a fundamental change in the way developers write code.

You already get the "problem" with the easiest use case of just loading data and printing a message:

Separating the SAME CODE into two adjacent cells will result in "unexpected outcomes" if you are not familiar with marimo or do not pay precise attention.

This gets worse when you get a little more going on:

To solve this requires littering the code with marimo specific "stop-commands" which is very unergonomic and cumbersome:

---

Thinking about this a lot and one of my findings is that usually developers expect the following when working with notebooks:

Every cell has an implicit dependency on ALL cells ABOVE

---

To be honest I think reproducibility in standard notebooks is a non-issue that is trivial to solve:

• restart + run all
• run in test/dev
• crash? -> adjust code

The same is not true for marimo because it will run but in unexpected ways/order which is very hard to predict/debug/solve.

In my opinion marimo has A LOT going for it!
py files, UI, output formatting, DB Connecitons, variable explorer, snippets, Documentation, ...

So with my experience it appears that a top-down execution while still being reactive would be a great way to solve this (all from my perspective and use-cases)

Thanks a lot for reading! Have a great day! Open for any discussion 🤓

[dmadisetti]

It's an good model. Livebook has a topdown data model which is pretty interesting and invalidates cells below when one above is run.

usually developers expect the following when working with notebooks: Every cell has an implicit dependency on ALL cells ABOVE

Hmm, but this is still a learned behavior no? When writing a library, developers may shift function order- but there's no expectation that the order itself matters. It might be an "unexpected outcome" the first time you use marimo - but I think that might just be a one time surprise. If there's not a variable tying together your logic (which indicates some dataflow)- is it reasonable an expectation that they should still be dependent on each other?

Anecdotally, the only time I have been burned by this behavior is when I have many long running cells and a few shorter running cells (show stats etc). It's a little frustrating when all the long running cells decide to run before I even get a single plot. I wouldn't call it unexpected, but definitely annoying. In the notebook I'm thinking of, I don't think top down would do much, but a more granular priority control would be nice (even DFS vs BFS execution)

---

Not saying you're doing it wrong (it's a notebook, you should be able to do whatever you want however you want)- but a little confused why you would break up the print statement and the execution cells. I don't think the outcomes are unexpected if you consider each cell to be an action, but maybe that's something we should emphasize.

Here are some perks of the current method:

• Put your imports and defs at the end, and have ultimately cleaner notebooks
• Moving around cells is a no-op, with no reproducibility problems
• No immediate promises, but a potentially automatically parallel notebooks
• No need for restart and run all + caching for smoothing over long running compute.

I think supporting top-down first class would let users slip use marimo like jupyter- but marimo is not jupyter, and one thesis is that the temporary learning curve is worth the ultimate gain.

but please push back! It's easy to get tunnel vision using the product for so long