What’s “modern” data science?

The reloading mechanism in the blog exercises the module reloader (https://docs.marimo.io/guides/editor_features/module_autorel...), to reload other files (not the notebook file), which is different from the watch flag.

The current version of the extension embeds the marimo user interface in PyCharm. We may in the near future have a more native-feeling embedding, but that's a little tbd.

Glad to hear you're enjoying marimo, and thanks for sharing the anecdote. I'll gladly accept the "thank you", but it's worth mentioning this extension was developed end-to-end by Kiran :)

Yup! Not affiliated in anyway, just a fan. I like jupyter but marimo's my go to for a few reasons:

- Automatic reactivity can be turned on (will trigger dependent cells if you uptade an upstream one) - Much nicer non-json file format (just python files, with a seperate output) - Much better virtual environment integration / managent (this is always a hassle with jupyter) - Widgets are great! - Better LLM integration (new marimo-pair means llm can inspect the actual python runtime objects) - It generally "looks" a lot nicer if you're using the web ui, which is nice.

The cell DAG enforces that there’s no implicit state, which reduces cognitive load for me a lot and provides some pressure to abstract experimental code into functions. In Jupyter this is left to user discipline and restart-and-run-all workflow

The reactive components are also really nice for interactive plotting and exploratory data analysis. You can do this in Jupyter but it feels less seamless somehow. Interactive marimo workflow feels like streamlit but in a notebook interface

One thing I miss from Pluto.jl workflow is `let` for lowering friction for exploratory or plot cells. In marimo you have to name a `_` prefixed function and then call it which is better than nothing but not as clean as `let`. This is a minor complaint that’s more down to language features though

marimo dev here, the pitch that got me working there is widgets!

This video highlights some fancy tricks: https://www.youtube.com/watch?v=qVSeOr3AIbc

You might like https://marimo.io/pair, it turns marimo into less of a notebook and more of a shared data/computational canvas for you and your agent

Why not make the agents make what you want with marimo?

As an SRE/ops (and I'm talking some years ago) it was often a pain point, especially with devs with a "works on my machine" attitude ; you would never get the exact requirements from them, I even saw a team of 2 who worked together with different versions of stuff on their respective machines. I also worked in some "offline" environments where once in prod you cannot pull anything from the internet, and you cannot install a compiler too, so it's quite hard to ship because some pip packages require to be built.

I found a way using (can't remember the tool name) which if you loop through the imports and gives it to the tool you get the package name, then I would build wheels to have all binaries and build a container or a VM with all that's needed, thus working completely around python package managers. This was a good enough workflow for the kind of deployment we needed.

Jupyter added a layer of complexity, I deployed it alongside RStudio as browser IDEs in docker swarm. Everybody wants a different set of deps and versions, so you have to keep track of everything, and also people may use things just for development that must not be shipped to prod, so you have to keep track of that too. Also some would develop notebooks on windows and expect them to work in linux VMs/containers and even in prod.

Nowadays devs ship container images anyway through a CI so it is less of an issue. In this era docker was far from being the de-facto everywhere, some people were still afraid of this, security didn't like it, etc.

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.

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. ```

"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something." - https://news.ycombinator.com/newsguidelines.html

It sounds like you're commenting about this from experience - if you'd like to share some of that, of course that would be welcome.

My biggest problem with Jupyter is hidden state. You have no idea what order the cells executed in and how many times to get to the current state. Pluto.jl and Marimo solve that by using reactivity to make state transparent. WYSIWYG.

I have also been thoroughly impressed how Marimo has engaged with AI agents. marimo-pair is fantastic.

What I like about Marimo notebooks over Jupyter:

1. They're just a python file so they work with python editors

2. There's no hidden state

3. I can import from them

4. I'm not accidentally committing base64 encoded image output anymore

Well, I've enjoyed it. It's easier to set up an run from a virtual environment than Jupyter notebooks. That was a big problem I had for years.

mind elaborate?