3 ms·

"unholy" "cleaner" "stateful" "bizarre" "bad taste" "hygiene" I'm not sure whether you're unaware or just feigning ignorance, but notebooks are frequently used

"unholy" "cleaner" "stateful" "bizarre" "bad taste" "hygiene" I'm not sure whether you're unaware or just feigning ignorance, but notebooks are frequently used to share partial results, often in the context of "research", however you may interpret it. Imagine a grad student or data scientist preparing some code and plots to show during a weekly meeting. In this context, the only thing that matters is quick progress and advancing understanding of a problem. The highly loaded words you employ while blasting the idea of uploading Jupyter notebooks are not relevant here. Wasting time on these things is seen as a bad thing. It's clear why someone using notebooks this way would want the interaction with Git and GitHub to be as seamless as possible: uploading something to GitHub is a very easy way to share it, even if this isn't the platonic ideal. It will probably cause you some pain, but I've known people to commit binary objects and PDFs to git to accomplish the same ends. ;-)

lynndotpy 3y ago
I agree entirely, outputs are great and I consider it best practice to provide notebooks with outputs provided. As a concrete example, this one-liner of Python code is much more interesting to those who don't recognize it when it's presented with the associated output. 4*sum([(random.random()**2 + random.random()**2)**.5 < 1 for _ in range(10**7)])/10**7 This is also useful, e.g. when viewing the read-only export of a notebook. (The one-linear above is a monte-carlo simulation which approximates Pi. On one run, this result came to 3.1410416.)
deleted 3y ago
[deleted]
tnecniv 3y ago
As someone who uses notebooks for research, outputs don’t play well with git. You can end up with very large commits that GitHub or wherever your repo lives may not like if you have a lot of plots and animations. Moreover, while research moves fast, reproducibility remains important. If your notebook is stateful, then when you share it I may not be able to recreate your result or you might have a bug due to something lingering in the notebook state. Having your outputs is convenient, but if I download the notebook, run it myself, and find that the code doesn’t run because there’s some variable that got defined earlier in your session but that code got deleted during iteration, that’s really not helpful. It’s the equivalent of handing someone your lab notebook but you kept erasing over early pages to make room for new content. That’s one example of a bug. You could easily introduce more subtle bugs where the state leads to invalid results.
- sfpotter 3y ago
  There are as many different "research workflows" as there are researchers. I'm a researcher and don't use notebooks for all the reasons you outlined and more. I have my own approach to dealing with reproducibility which is low tech and works for me and my collaborators. My comment is meant to point out that there are many researchers who view all of the problems you describe as unimportant and not worth spending time on.

lynndotpy 3y ago

I agree entirely, outputs are great and I consider it best practice to provide notebooks with outputs provided. As a concrete example, this one-liner of Python code is much more interesting to those who don't recognize it when it's presented with the associated output. 4*sum([(random.random()**2 + random.random()**2)**.5 < 1 for _ in range(10**7)])/10**7 This is also useful, e.g. when viewing the read-only export of a notebook. (The one-linear above is a monte-carlo simulation which approximates Pi. On one run, this result came to 3.1410416.)

deleted 3y ago

[deleted]

tnecniv 3y ago

As someone who uses notebooks for research, outputs don’t play well with git. You can end up with very large commits that GitHub or wherever your repo lives may not like if you have a lot of plots and animations. Moreover, while research moves fast, reproducibility remains important. If your notebook is stateful, then when you share it I may not be able to recreate your result or you might have a bug due to something lingering in the notebook state. Having your outputs is convenient, but if I download the notebook, run it myself, and find that the code doesn’t run because there’s some variable that got defined earlier in your session but that code got deleted during iteration, that’s really not helpful. It’s the equivalent of handing someone your lab notebook but you kept erasing over early pages to make room for new content. That’s one example of a bug. You could easily introduce more subtle bugs where the state leads to invalid results.

sfpotter 3y ago
There are as many different "research workflows" as there are researchers. I'm a researcher and don't use notebooks for all the reasons you outlined and more. I have my own approach to dealing with reproducibility which is low tech and works for me and my collaborators. My comment is meant to point out that there are many researchers who view all of the problems you describe as unimportant and not worth spending time on.