Hi; I'm the author of this post, and one of marimo's original developers. Thanks for taking the time to read this post, and for looking at marimo.
> With Marimo, can I check the outputs directory into version control in a reasonable way and have it stored for posterity? Is that .ipynb?
You can snapshot to ipynb automatically while a marimo notebook is running, or after the fact. You can also snapshot as HTML, which marimo can hydrate back into a notebook.
> Is there a way to convert a stored .ipynb checkpoint back into the marimo format?
Yes, `marimo convert notebook.ipynb -o notebook.py`.
marimo was originally commissioned by, and designed in collaboration with, scientists at Stanford's SLAC National Laboratory. These scientists were heavy users of Jupyter, but decided they needed something like marimo to solve two main problems they encountered with Jupyter notebooks: computational reproducibility, and publishing interactive science communication on the web.
We have co-authored an article with these scientists, explaining how these problems and how marimo solves, which you can read here: https://marimo.io/blog/slac-marimo.
From our article:
> In 2019, a study from New York University and Federal Fluminense University found that of the 863,878 Jupyter notebooks on GitHub with valid execution orders, only 24% could be re-run, and just 4% reproduced the same results.
Many scientists (these scientists and myself) use notebooks as a critical part of the scientific process. Jupyter notebooks are notorious for being plagued with reproducibility issues due to hidden state, to the extent that the authors of Jupyter wrote a paper titled "Ten simple rules for reproducible research in Jupyter notebooks" [1]. In my mind, these rules are not simple nor convenient. One is to periodically restart the kernel to make sure you don't accumulate hidden state — untenable for expensive notebook. Another rule is in fact to use version control (Git):
> Version control is a critical adjunct to notebook use, because the interactive nature of notebooks makes it easy to accidentally change or delete important content. Furthermore, since notebooks contain code, and code inevitably contains bugs, being able to determine the history of when a given bug you have discovered was introduced to the code vs when it was fixed – and thus what analyses it may have affected – is a key capability in scientific computation.
In my own PhD, I used Jupyter notebooks extensively to see my data while I worked on it, and to produce figures for papers [2]; sometimes, these notebooks took a very long time to run. I have a background in software engineering, so I was able to make my notebooks more or less reproducible, though I wasted many hours debugging inconsistencies due to hidden state (one example: delete a cell, but its variable are still in memory!) My co-authors, however, often did not have a background in software. They also used Jupyter notebooks. But when I tried to run their notebooks, either they didn't work at all (packages and computational environment not properly documented), or when running I got different results than the ones serialized in the notebook (notebook author ran cells out of order, or ran side-effecting cells multiple times, etc -- hidden state). This was a huge problem and really a non-starter for computational science.
Yes, you can get Jupyter/Ipykernel to work for you if you try hard enough, if you are experienced enough, and if you are willing to eat enough pain (sometimes literally -- I know of someone who got an incorrect tattoo due to hidden state in a Jupyter notebook that rendered a design for their tattoo; the notebook author forgot to "restart and run all" after making a change). But the imperative nature of the REPL makes it a fundamentally error-prone experience. Our philosophy with marimo is that notebooks should be reproducible by default.
Hope this helps. It's still possible that marimo is not for you, but at least for scientists who use notebooks to conduct research, or want to share interactive articles on the web without paying for compute, I do believe it has something compelling to offer over traditional notebooks like Jupyter.
[1] https://arxiv.org/pdf/1810.08055
[2] https://web.stanford.edu/~boyd/papers/min_dist_emb.html