Why Jupyter is data scientists’ computational notebook of choice

The hard part is that introducing a tool like git (which requires you to choose moments to take a snapshot of the file, and then add some commit message) breaks the flow of interactive experimentation that notebooks are so good for. And then we need to find a way to make those commits useful, because the time ordering of commits could be different from the time order in which cells were run! That is what is crucial to making computations reproducible — viewers should be able to replay the history of how a notebook result came to be. (EDIT: Note that this is the case only for stateful computations -- if a notebook interface was used to construct a dataflow graph (like spreadsheets) with values updating live, then this wouldn't be so much of a problem. More fundamentally, it is not at all obvious that thinking of notebook contents as akin to code is the best way to use version control)

I wonder whether there is a solution along the lines of auto-committing each cell before it’s executed and the results just after the cell is executed. Otherwise a user has to do too much manual organizing, which is a problem the notebook should ideally solve. When a user is happy with the experiments and the provenance of their results, they should be able to use an interactive rebase to create a cleaner version to share/archive.

> What was the earliest of these tools? Mathcad? Mathematica? Maple?

The first version of MathCad (for DOS) came in 1986, but it's difficult to find info on how it looked like. Did it already have the notebook interface? This is how MathCad looked in 1989:

https://en.wikipedia.org/wiki/File:Mathcad_252_screenshot.pn...

Mathematica 1.0 came in 1988, and it definitely had the notebook-interface.

https://reference.wolfram.com/legacy/v1/contents/whatis.html

Wikipedia says Maple got its first graphical interface in 1989.

> However, many of the practices we have grown into as sound programming advice seem to be largely thrown out the window for these notebooks.

The exact same thing happened with the arrival of the www.

If you are interested in workbooks which are collaborative and versioned, take a look at http://datalore.io/

Version control is transparent and integrated and it's possible to work with workbooks collaboratively.

I think they fundamentally json is just the wrong format for these files. Speaking from (ancient and limited) experience I made a little notebook-style interpreter for learning scala back in 2009 or so called scalide. It saved its files ("scalapads") to XML. XML actually worked better in some ways since most of the code could live between the tags unescaped (sans &) so it merged / diffed the user code well. The meta-level stuff (cell boundaries etc) needed by the notebook ... not so much.

In json the code has to be escaped into strings, and json is really finicky about syntax (e.g. no trailing commas). So it doesn't work well.

I never got the chance to redo it, however the solution I was leaning to for my post "I won the lottery, I can work on fun stuff" attempt was to store the meta-code in a version of the host language(s), with some simple syntax that could live comfortably in the comments of various different languages to do things like encode the cell divisions and so on.

Basically something like: #notebook[lang=python]

#cell[lang=python] def add(x,y): return x + y #endcell

//notebook[lang=scala]

//cell[lang=python] def add(x: Int, y: Int) = x + y //endcell

This I think would be beneficial for a couple of reasons.

1. Better diffing / merging.

2. One click toggle between show source and view as notebook mode, which would really allow this to work in an IDE like vscode pretty seamlessly. The cells become something akin to //#regions in the IDE. But at the end of the day you are still editing a source code file, so you can edit the whole file easily.

3. The keyboard shortcuts for executing and jumping between cells would generally work in raw code mode, so you could just edit there continuously and manually writing out //cell //endcell. Also the executing results could appear in block comments inline in the editor, off to the side, or in a popup above, the code you are editing.

4. The IDEs could uprender the comment-syntax into cells as they gained better support for the paradigm (similar to how they do for code folding / syntax higlighting already).

5. Eventually, perhaps a cross language, metasyntax could be established to make things a bit more concrete than magic comments (get ready for some serious bikeshed painting though!)

The closest I have seen anything come in this regard is Quokka however it's not quite all the way there.