Representing Python notebooks as dataflow graphs • Hacker News Board

Re: Representing Python notebooks as dataflow graphs

#31

Post by akshayka » Sun, Aug 10, 2025, 7:53 PM UTC

ayhanfuat wrote: post #26

akshayka wrote: post #22

Earlier quoted context omitted.

What kind of muscle memory is holding you back? We recently added support for Jupyter-style command mode in keyboard shortcuts [1]. We're currently rewriting our VS Code extension to feel native, similar to how Jupyter feels in VS Code. Anything else we can help with?

Ah that's great to hear. For me it is mostly the command mode. Is it only create / copy / paste for now? Can I also do the same for move / split / delete / undelete?

Sorry I forgot the link. We have shortcuts for those as well. If any are missing please file an issue and we can consider adding them.

I forgot the link: https://docs.marimo.io/guides/editor_features/overview/#conf...

Re: Representing Python notebooks as dataflow graphs

#32

Post by akshayka » Sun, Aug 10, 2025, 8:03 PM UTC

suuuuuuuu wrote: post #28

akshayka wrote: post #19

Earlier quoted context omitted.

Thanks for the comments. I'm the original creator of marimo. Habitually running restart and run all works okay for very lightweight notebooks, but it's a habit you need to develop, and I believe our tools should work by default. It doesn't work at all for entire categories of work, where computation is heavy and the cost of a bug is high. From the blog, you will see that reactive execution not only minimizes hidden s…

I would consider replacing my jupyterlab usage with marimo were it less opinionated about workflow - it offers a lot of benefits that aren't tied to its execution model. I like the editor/interface and the representation as python files for portability, version control, and the ability to import from other notebooks, but I have no interest in changing my workflow (in particular insofar as marimo is restricted compare…

Thanks for the feedback. We decided early on against having a “non-reactive” mode. It would negate many of our core benefits (including importing from other notebooks), and it would also lead to a fragmented ecosystem — if someone shared a notebook with you, your experience with it would depend on whether it was executed in “reactive” or “non-reactive” mode. Still I appreciate the kind words about our editor and file format, and am sorry we can’t accommodate your use case.

We describe why we opted against “disabling” the graph at the end of this blog: https://marimo.io/blog/lessons-learned

Re: Representing Python notebooks as dataflow graphs

#33

Post by jcheng » Mon, Aug 11, 2025, 3:43 PM UTC

philsnow wrote: post #27

As an outsider to the whole notebook ecosystem, I am absolutely gobsmacked that the representation of the notebook makes it possible to have out-of-date intermediate results. Haven't they been around for like 10+ years? This is one of those things that is blindingly obvious to people in adjacent sectors of the industry, but maybe there just hasn't been enough cross-pollination of ideas in that direction (or in either…

For as long as there have been Jupyter notebooks, there have been people saying "Wait, what??" But there have been way more people using them, and finding them pretty effective despite their inherent lack of soundness.

I personally fall into both camps--both horrified at the execution model but also, it's not actually caused problems for me as it's second nature to restart the kernel when changing upstream cells.

That said, marimo feels like a significant step forward and I'm rooting for them to succeed.