What’s wrong with computational notebooks?

Co-author of the study here. Let me know if you have any questions or how you overcome some of the problems we identified!

I want a notebook where causality can only flow forward through the cells. I hate notebook time-loops where a variable from a deleted cell can still be in scope.<p>1. Checkpoint the interpreter state after every cell execution.<p>2. If I edit a cell, roll back to the previous checkpoint and let execution follow from there.<p>I can&#x27;t tell you how many times I&#x27;ve seen accidental persistence of dead state waste hours of people&#x27;s time.

I used Mathematica’s notebook interface quite heavily 15-20 years ago; Jupyter’s interface is a clone of that in many ways.<p>At the time, my workflow was to use two different notebooks for everything: foo.nb and foo-scratch.nb. I’d get things working a piece at a time in foo-scratch.nb, not caring at all how it looked, not having to worry about leaving extra output or dead ends of explorations lying around; then the refined cells would be copied over to foo.nb, which would get pristine presentation, and which I could run top-to-bottom.<p>This workflow worked pretty well for me: very clean reproducible output, with the ability to easily refer back to all the steps of how I’d derived something, along with copious detailed private notes.<p>I never had to use it but I’m pretty sure each cell even had its modification time stored in the metadata in case I wanted to view a chronological history.

See also Joel Grus&#x27; talk, &quot;I Don&#x27;t Like Notebooks&quot;: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=7jiPeIFXb6U" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=7jiPeIFXb6U</a><p>slides: <a href="https:&#x2F;&#x2F;docs.google.com&#x2F;presentation&#x2F;d&#x2F;1n2RlMdmv1p25Xy5thJUhkKGvjtV-dkAIsUXP-AL4ffI&#x2F;edit" rel="nofollow">https:&#x2F;&#x2F;docs.google.com&#x2F;presentation&#x2F;d&#x2F;1n2RlMdmv1p25Xy5thJUh...</a>

I&#x27;m someone who has been programming for a very long time and has been using notebooks for a reasonably long time (and almost always starts projects with them), my feeling is that they are a bit like C in that they make it easy to accidentally shoot yourself in the foot if you aren&#x27;t careful. I always strive to end up with a notebook that can be &quot;Run All&quot; from a fresh clone, and I&#x27;d say that I&#x27;m successful with that maybe 60-70% of the time, and am close enough that I can fix it in the remainder.<p>As the article (and the many others like it that have frequently cropped up as soon as IPython Notebooks first started ramping up in popularity) points out though, a lot of newer users don&#x27;t have the discipline to ensure that they&#x27;re not jumping around too much. It&#x27;s not a problem for them in the immediate term since they know how the state ought to work, but then it becomes a mess when they try to share it with someone else (or to run it themselves again 3 months later).<p>The challenge though is that the data analysis workflows that it allows are unbeatable by any other tools I&#x27;ve tried. In the end, it may just be that it&#x27;s the worst form of data programming except for all of the others that have been tried.

I interned @ Google AI last summer; used notebooks nearly everyday. Estimated productivity gain is 3-5x.<p>Biggest tip I have is to turn auto reload on, then write the bulk of your code as modular functions and call functions within your notebooks. Keeps the notebook tidy and it’s easier to push your code this way.<p>It’s also easier for sharing since most people viewing your notebooks (mentors, people outside your team) are interested in results&#x2F;artifacts such as metrics, generated text, images, audio, which notebooks display well (not your code).

(A frequent Jupyter Notebook user here. For data exploration, and teaching deep learning - then Colab is indispensable.)<p>The main question is: what are the alternatives, for data exploration (and sharing its results). Similarly, for data science tool demos, Notebooks shine.<p>IMHO the problem is not in the notebooks, but in how they are being used (i.e. the workflow). By writing scripts in py files, and using notebooks only to show their results (processed data, charts, etc) we get the best of both worlds.<p>The only build-in problem with Jupyter Notebooks is JSON, mixing input and output (and making it pain to work with version control). But here RMarkdown (and a few other alternatives) work well.

I don&#x27;t get why anyone one who knows how to use an IDE would ever use a notebook, the coding experience is garbage in comparison. I understand they started as a way to get STEM kids coding quick, but now they are like a standard in data analysis and data science, with those people needing experienced devs to translate the notebook into production code. This just drives the silo walls up higher.

I don&#x27;t know what this document is meant to do but you will have to take my Jupyter-lab instance from my dead cold hands.<p>I love notebooks, I work fast, line by line I execute commands and I immediately see the output (dataframes or graphs). For complex code I have an editor open (in jupyter-lab or vscode) for some functions and classes. But the main developing is done in the notebook, anything that ends in a module start in my notebooks.<p>As a biologist that learned to program after 30 I just don&#x27;t understand how you can develop data processing code without such a close handle on dataframes and without checking in graphs&#x2F;visualizations if your code does what you expect. I don&#x27;t see how I would do that in pure vscode of other IDEs.<p>I also don&#x27;t understand this sentence: &quot;Once the data is loaded, it then has to be cleaned, which participants complained is a repetitive and time consuming task that involves copying and pasting code from their personal &quot;library&quot; of commonly used functions.&quot; What is the alternative? Not cleaning the code? And why copy and paste when you can perfectly fine have your own shareable module on the side? I guess most notebook users do some kind of hybrid development.

The FastAI people have been working on a lot of these issues with their NBDev too: <a href="https:&#x2F;&#x2F;www.fast.ai&#x2F;2019&#x2F;12&#x2F;02&#x2F;nbdev&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.fast.ai&#x2F;2019&#x2F;12&#x2F;02&#x2F;nbdev&#x2F;</a>

I love jupyter notebooks. Without them, I wouldn’t have been half as productive as I was during my PhD.<p>Here’s a post I wrote just a few weeks ago describing some of the conventions that I established for myself over the course of 5 years:<p><a href="https:&#x2F;&#x2F;jessimekirk.com&#x2F;blog&#x2F;notebook_rules&#x2F;" rel="nofollow">https:&#x2F;&#x2F;jessimekirk.com&#x2F;blog&#x2F;notebook_rules&#x2F;</a><p>I suspect that a lot of the conventions I describe help mitigate problems described here, some of which should be strictly or optionally enforced by the notebook instead of the user.<p>(The site’s very much a work in progress, so expect to see odd and broken things if you go poking around.)

No mention of <a href="https:&#x2F;&#x2F;observablehq.com" rel="nofollow">https:&#x2F;&#x2F;observablehq.com</a> notebooks? They’re the best I’ve found in the “Share and collaborate” and “As products” category. JupyterLab is still pretty great for exploratory stuff, but visualization possibilities in observable are incredible.

The problem of notebooks has been solved by the Python extension in Visual Studio Code (and some other editors too, although VS Code is the one I&#x27;m most familiar with).<p>Editing an ordinary Python file, if you insert the comment &quot;# %%&quot;, you turn everything between that comment and the next &quot;# %%&quot; (or the end of the file) into a code cell that can be submitted to the ipython kernel, just as in a Jupyter notebook. The editor splits into two halves, the left half your Python file and the right half the Jupyter notebook window with submitted code and formatted output (e.g., DataFrames look pretty, plots display normally, etc.). When you&#x27;re done running everything, you can export the result as a Jupyter notebook. Because you&#x27;re editing an ordinary Python file, standard features like version control and importing the file you&#x27;re editing into other files (you cannot normally import .ipynb files IIRC) work normally.<p>And of course since VS Code is a real editor&#x2F;IDE, you can double click a file and have it open right up (no resorting to a Terminal to start your Jupyter session) and you get syntax themes, a built in Terminal, a git UI, code snippets, documentation on hover, vim mode if that&#x27;s your thing, etc.<p>The only downside I&#x27;ve found is that the Python extension doesn&#x27;t incorporate ipython&#x27;s autocomplete in its own autocompletion, but that&#x27;s a small price to pay for getting to treat .py files as notebooks.

So literally all of these complaints are about their particular implementations of notebooks, not the concept of computational notebooks in general, or are all computational notebooks destined to have unstable kernels?<p>In my mind, notebooks <i>should</i> be married to a functional style of programming, where you use the notebook&#x27;s markup to thoroughly explain and document your functions. Below your &quot;function definition&quot; section, you keep a &quot;trying things out&quot; section where you actually plug the data into your functions for debugging&#x2F;visualizations. You can&#x27;t shoot yourself in the foot with variables because all the work is done in your function&#x27;s lexical scope. You can shoot yourself in the foot with stale function definitions, but a good notebook interface gives you the ability to clear function definitions and run groups of cells, so you can make sure you always run your functions in a group that starts with a &quot;clear function definitions&quot; cell.<p>When you are done, you just cut the &quot;trying things out&quot; section into a second notebook which references the functions in the first and <i>viola</i>, you&#x27;ve got a very well documented library of functions, and a new work notebook where you can freely polish your visualizations&#x2F;whatever.

This is a solid list. It will be even better if juxtaposed with current efforts to solve each of these problems - every DS I know is addressing at least 2-3 of these with some pet tools in their own environment. For example, we use Panel and Holoviews to make data exploration much easier. I have a feeling the ecosystem would improve faster if we had an index of (partial) solutions aligned with this problem set.<p>One category left out of the list: testing of data pipelines (c.f. great expectations).

I use Jupyter Lab with Python every day. It&#x27;s where I do my initial data exploration and cleaning. Jupyter Lab is not perfect, but most of these findings seem like they are more issues of inexperience with technology and programming, not computational notebooks.

I have been heads down in jupyter for the past couple of weeks and I finally realized I just <i>DO NOT LIKE IT AT ALL</i>! Cracks started appearing and then suddenly there was an avalanche of disappointment.<p>The first crack -- it&#x27;s almost impossible to build a nice presentation in Jupyter, because you always have to show your code and its stderr. I imported all the TeX goodness, and it looked pretty nice, but I couldn&#x27;t show the output without showing the TeX code. Importing the TeX interpreter is quite non-standard and means that my notebook doesn&#x27;t play well with the public servers. I also got burned by some kind of permissions issue, so that all my charts ended up being invisible to read-only users.<p>The second crack -- I can only look at the code from within my own jupyter server. The source is buried in a very noisy json format.<p>The third crack -- Who wants to write code in the impoverished browser based editor provided? How many times have I deleted a closing brace that was automatically inserted incorrectly? How can I do a global search and replace?<p>The fourth crack -- I can&#x27;t test my code unless I include all the tests in the notebook!<p>I&#x27;m complaining. I realize that I don&#x27;t have anything constructive to offer, and I&#x27;m really a beginner. However, I think some of my disappointment is justified, as I think it was reasonable to assume that I could build my notebooks to be next level presentations.

I think Atom’s hydrogen and VSCode’s python are best-in-class Jupyter clients that achieve everything Jupyter Lab set out to do with more and better features. I develop scripts that function top to bottom with a notebook side-by-side that on a keyboard stroke executes code blocks from my script in the notebook.

I think Computational Notebooks are a great idea, and yet I have the feeling that we are in the process of seeing them overapplied. They are wonderful for certain situations, and teaching or demonstrating code to others is right in its sweet spot.<p>I get the impression that people are creeping in the direction of trying to do everything with one tool, which sounds like it would end up in the same swamp that Eclipse went into. Sometimes, you need to use different tools for different tasks, and not everything should integrate. Just my opinion.

I think that all the pain points of the article are a result of not using notebooks for their purpose. In my opinion, notebooks are good for:<p>1. POC&#x2F;MVP: Showing that what you want to do will work before making a full structure. 2. Creating PDF&#x2F;HTML documents with code and output. 3. Exploratory data analysis and visualization.<p>I think many of the data scientists in the article go well beyond what a notebook is. A notebook is where you start, but should never be a production tool.

Jupyter notebooks are great for many purposes. They have, however, two really tragic shortcomings:<p>1. They are stored by default in stupid json files instead of plain source code with comments.<p>2. The text editing interface inside the browser is horrific and very difficult to normalize (e.g., disable &quot;smart&quot; closing of parentheses, disable the capture of classic unix copy-pasting, etc).

This is a great list, and totally matches my experience. I also agree this is solvable with tooling.<p>A) VS Code &#x2F; IDE needs to be the primary editor B) Results are not stored with source C) Export (build) allows packaging for whatever platform.<p>Python notebooks especially also use some crazy mutable APIs. In general notebooks align with other code written by people who aren’t usually software engineers building production systems. They’re much more about getting things done, APIs and tools are less questioned, a lot of pain is swallowed because PhDs have plenty of time to write a few lines of code. I don’t want to sound disparaging towards these people, it’s just a different set of tradeoffs from writing production grade software.

As a computer scientist&#x2F;software engineer, please allow me the question: Why would I prefer a notebook over e.g. equivalent python script(s) in a git?<p>I first saw jupyter notebooks when my sister (physicist, non-programmer) used it for analyzing economical data with pandas. Run-time for the full data set was half a day (and IMHO for that analysis SQL would have been better suited). I understand that as a non-programmer it looks alluring, but once the language proficiency is build up, why not use an IDE and run the code on a shell?

<a href="https:&#x2F;&#x2F;datalore.io" rel="nofollow">https:&#x2F;&#x2F;datalore.io</a> has (1) a reactive Datalore kernel that solves the reproducibility problem. It recalculates the code automatically when something is changed, and recalculates only the changed and the dependent code; (2) good completion; (3) online collaboration; (4) read-only sharing; (5) publishing; (6) sensitive data can be saved in .private directory that is not exposed when the notebook is shared with read-only access

There are these and other problems with CNs:<p>0. They try to be &quot;be-all, end-all&quot; proprietary container documents, so they lack generality, compatibility and embeddability. It would be better if live code try-out snippets were self-contained and embeddable in other documents: HTML, other software, maybe PDF, LaTex or literate programming formats. Maybe there should be standard, versioned interpreters for each kind of programming language in WebAssembly and cached for offline usage by the browser for inclusion in documentation, papers, etc.?<p>1. For prototyping, it is better to have try-out live code (and&#x2F;or REPLs with undo) for prototyping like what is Xcode&#x2F;iOS Playgrounds for Swift or ReInteract was for Python.<p>2. Computational notebook software, that I&#x27;ve seen, are terrible, complex, fragile and messy to install. The ones I&#x27;ve seen make TeXLive look effortless by comparison.<p>3. Beyond replicability what goal(s) are CN really trying to solve?<p>3.0. For replicability itself, why not have a GitLab&#x2F;BitBucket&#x2F;GitHub repo for code and a Docker&#x2F;Vagrant container one-liner that grabs the latest source when built? Without a clear, consistent and simple build process, there is no replicability, only wasted time, headaches and fragile&#x2F;messy results.<p>3.1. Are CNs &quot;hammers&quot; for &quot;nails&quot; that don&#x27;t exist?

Good list.<p>Their observations bring to mind the benefits of watching people program on YouTube or video where you learn a style of working you may not even have considered.<p>However there is one other issue that is not on the list: because a notebook is meant to be read or shared, I always feel like my work is public and feel less inclined to play around and just take a look at things. When I do “transfer” my work to a notebook, it’s only surprising or interesting things that suppress the discovery process.

One thing that I find to be incredibly useful is the keyboard shortcut `00` (press zero twice while focus is outside of a cell), which will restart the kernel, clear all output and re-run the whole notebook.<p>This way I&#x27;m sure that &quot;library code&quot; that I&#x27;m editing in parallel in a real text editor is up to date in the notebook and also solves the limits the confusion due to run-out-of-oder problems.<p>The overall workflow is something like this:<p><pre><code> 1. explore using thing.&lt;TAB&gt;, thing?, and %psource thing 2. edit draft code chunk or function 3. when chunk 80% done; move it to a module and replace it with an import statement 4. press 00 to re-run everything, then GOTO step 1 </code></pre> The key to preserving sanity is step 3—as soon as the exploration phase is done, move to a real text editor (and start adding tests). Don&#x27;t try to do big chunks of software development in the notebook. You wouldn&#x27;t write an entire program in the REPL, would you?<p>Sometimes I keep around the notebook as a record for failed explorations or as a &quot;test harness&quot; for the code, but most of the time it&#x27;s throwoutable since all the useful bits have moved into a normal python module&#x2F;script under version control.

The reality is — notebooks are and need to be developed as an app platform ...<p>In order to do notebooks properly — you need:<p>1. discovery (Ideally static discovery) of all the state the notebook needs, and the bulk of state the notebook will&#x2F;could manipulate during its execution. Your container needs to intercept the filesystem and the networking apis that will be invoked so that a determination of the state that results from these operations can be observed by the runtime and shimmed appropriately for reproducibility and for performance optimization<p>2. The notebook (and the runtime inferred model of all the required inputs) needs to be repo stable — I Should be able to write a notebook app that reads from the file system on my development host, deploy it somewhere, and the runtime should take care that wherever that however that post deployment file system read is implemented matches my local development semantics<p>3. Pplatform level dependency graph needs to exist to model re-execution requirements automatically — incorporating code changes and external state<p>Apple could build this And “notebook-os” would be the correct conceptual framework for it ... anything less is always going to leave us severely wanting

For those asking “what’s the alternative”, RStudio and Matlab already solved the design problem (though they could be better executed).

My main use for notebooks is a simple way to constantly hold a whole large dataset in memory. That way if I want to try some feature reduction or remove some bad result, I can just do that and not wait 10 minutes for my slow PC to rerun my import code. I feel like an easy way to do that in base python would draw me away from notebooks.

Obviously it&#x27;s pretty hard to make general criticism of the Notebook GUI. This is especially without comparing to a specific other user interface for data scientists, such as a traditional REPL terminal, or some other command line tools?<p>The Python world gives a good example about the sheer complexity of a notebook infrastructure. The is IPython, there is Jupyter Notebook, JupyterLab. There is even stuff like the SageMathCloud (nowadays called CoCalc) which is basically a web GUI to a VPS combining command lines and various notebooks. And hell, most of these web based interfaces try to make sharing easy.<p>Mabye we should start comparing these (mostly OSS) tools to the traditional notebook GUIs of Matlab and Mathematica, something we used in the 90s and 2000s. From my feeling, they were more robust, could handle large data better, but they lack all the tooling we get for free in the web.

I would love to see some gifted people using this info to further improve tools like nteract[0].<p>It already eases a lot of pain you may have in comparison when setting up jupyter notebook without the knowledge of a software developer.<p>[0]: <a href="https:&#x2F;&#x2F;nteract.io&#x2F;" rel="nofollow">https:&#x2F;&#x2F;nteract.io&#x2F;</a>

I&#x27;m not sure I understand the issue about the user repeatedly tweaking parameters for their data visualization. If anything, that is a reason notebooks are so nice. The repeated tweaks are due to the notebook format, its because that&#x27;s an inherent part of the data visualization process, where the end result of a particular parameter choice is hard to predict how it will look with a given data set. So the same process would occur whether one was using a notebook or a script, but with a script it becomes much more cumbersome to actually see the result. In a notebook, the parameter tweaking for a data visualization is immediately followed by the result.<p>I definitely agree with most of the other points though.

I think it&#x27;s easy to do notebooks wrong, but possible to do them right. I try and do quick prototyping in notebook cells before moving it off to a separate .py file, and avoid keeping any code that does anything other than visualisation or parameter setting inside a cell long-term. That way, if you need to run something &quot;in production&quot; (whatever that means in your context), you don&#x27;t end up having to pick apart and re-write your code -- you just import the .py file you wrote along the way.<p>For me, notebooks are a super handy way of visualising and sharing results during meetings, and it&#x27;s difficult to imagine a more convenient alternative.

I tried to encourage our team to use notebooks, however everyone prefers using PyCharm and git for sharing code. We dont have much visualization, which might be the reason, but I was surprised just how many people just hated it.

Direct link to the preprint: <a href="http:&#x2F;&#x2F;web.eecs.utk.edu&#x2F;~azh&#x2F;pubs&#x2F;Chattopadhyay2020CHI_NotebookPainpoints.pdf" rel="nofollow">http:&#x2F;&#x2F;web.eecs.utk.edu&#x2F;~azh&#x2F;pubs&#x2F;Chattopadhyay2020CHI_Noteb...</a><p>Interesting study, I like the mixed-method approach. A quick glance at the industry of the participants suggests that there might be a bias towards structural data (which I think is actually acceptable as that makes up a huge chunk of the non-academic ML-Notebook work) Edit: The authors acknowledge this in the &quot;Limitations&quot;.

This is akin to reviewing how well a screwdriver drives nails. Yes, it has problems. That doesn&#x27;t mean it&#x27;s a bad tool - you&#x27;re just not using it right. Does it require discipline? Yes, but so does the screwdriver. That being said, I think jupyter specifically has some legacy issues around format, and I prefer R markdown. As much as I love pycharm, it&#x27;s never going to do more than replicate the notebook experience. IMHO, the main author publishes on code UI&#x2F;UX, the title seems more like click bait. Not sure why it&#x27;s so upvoted.

I quite like the Spyder approach: Pure python code that is segmented into cells by inserting a special comment line.<p>The cells can then be individually executed in an ipython shell, or the entire script can be run with the regular python interpreter. This makes it easy to tweak the individual parts without having to re-run everything. In contrast to jupyter notebooks you still end up with a valid python script that can be easily version controlled.<p>I just wish that I could use vim instead of the Spyder IDE.

I wrote a plugin for ipython that some people might find useful: <a href="https:&#x2F;&#x2F;github.com&#x2F;uiuc-sine&#x2F;ipython-cells" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;uiuc-sine&#x2F;ipython-cells</a><p>It lets you do linear execution of blocks like in Jupyter, but in a normal .py file. Obviously more lightweight than Jupyter and you get to use your regular editor.

I work at <a href="https:&#x2F;&#x2F;www.deepnote.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.deepnote.com&#x2F;</a>, we are trying to tackle some of the pains mentioned in the article (setup, collaboration, IDE features like auto-complete or linting).<p>We are still early access, but if you are interested in an invite just let me know. My email is filip at deepnote dot com.

I&#x27;m curious. How do people protocol their experiments? When I started, I used to just keep the cells but that lead to very long and impossible to parse Jupyter notebooks. I have since opted for keeping a journal.txt file in Atom where I write down hpyerparameter configurations, epochs run and results (for ML). But that feels a bit awkward as well.

At Gigantum, we&#x27;re trying to solve some of these issues too. A Gigantum Project lets you run Jupyter or RStudio in a container that is managed for you. Everything is automatically versioned so you can sort out exactly what was run, by who, and when.<p><a href="https:&#x2F;&#x2F;gigantum.com" rel="nofollow">https:&#x2F;&#x2F;gigantum.com</a>

Small note: why post an image with the pain points if I need to check the list below to understand what&#x27;s written?

Previous discussion:<p>General: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=18336202" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=18336202</a><p>Version Control: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=21661013" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=21661013</a>

People love jupyter notebooks for the same reason people love Excel.<p>This is intended to be a Zen-like Koan, so take it as you will.

One idea for a pain point not mentioned: better variable persistence. If I declare a variable, then delete the cell I declared it in, the variable persists. I&#x27;ve had this cause issues because if I use the deleted variable by accident, it will work fine right up until a kernel restart.

I don’t get the popularity of these things - I think you have to have started out with them to like them.

For emacs org-mode users this <a href="https:&#x2F;&#x2F;github.com&#x2F;dzop&#x2F;emacs-jupyter&#x2F;blob&#x2F;master&#x2F;README.org" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;dzop&#x2F;emacs-jupyter&#x2F;blob&#x2F;master&#x2F;README.org</a> is worth looking into.

I’m surprised no one has mentioned what I see as the biggest failings of notebooks: poor handling of connection loss &#x2F; re-connection. The kernel will continue to run, but a connection hiccup will often make the notebook UI stop updating (and lose any kernel output).

Notebooks are bad and unreliable. You are repeating your code all the time, you are limited to work with smaller datasets. If you are into visual data analysis use Orange or other similar data mining tools. We allow usage of notebooks only for presentation purposes.

It is interesting to me how this talks about &quot;computational notebooks&quot; but it seems to be about Jupyter and derivatives thereof -- RMarkdown notebooks run inside of the RStudio IDE, and they don&#x27;t use the term &#x27;kernels&#x27; like Jupyter does.

What are the currently available CI options for notebooks? You&#x27;d think this would be one of the first tools people would need to make sure notebooks are reproducible, but there seems to be little sign of CI usage.

Streamlit is imo the best alternative. I was a beta tester and I found that it encouraged good coding practice without sacrificing too much functionality. I highly recommend that other data scientists check it out.<p>Streamlit.io

Trying my best to solve some of these: <a href="https:&#x2F;&#x2F;github.com&#x2F;wrnrlr&#x2F;foxtrot" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;wrnrlr&#x2F;foxtrot</a>

Performance is another pain point, at least for jupyter

Why no Mathematica?

Notebooks are sort of like democracy, its the worst form of government except all the others.<p>You need to pick the best tool for the job, and often times in machine learning that tool is a notebook.

Why not teach data scientists how to write software effectively? Those are smart people, it’s not like using version control, writing unit tests and extracting common code into libraries is rocket science.

What is wrong with life? Many but let us appreciate how to use it more instead of seemingly criticise it.<p>The world is so much better with you alive. So is the founded tool of computational notebook. Not sure I read it covered R notebook which is really good to share info and analyst. Just wonder how to use it better.<p>Of course they can always improve on it. But I would promote more expansion - How about a lisp notebook, a clojure notebook, a js notebook and a forth notebook.<p>The real problem is can you have oo notebook ... it is more “serial” and graphic and data. But not for the “messy” class or trigger Based system. Hence if I may, the real problem is the scoping. It is so hard to visualise a live oo system. Unlike a live functional or even a stack based system.<p>It is not life that is the problem. Even useless life has its use, as long as it is alive. But if it is not reaching there an alternative may have to think about. Just like we cannot be there we send in our voyagers outside solar system.<p>Be long and prosper.