1) Version Control! I normally run a single user git workflow and even that is a problem with Jupyter notebooks.
2) Code Execution is all at once or in chunks in R Notebooks. So I can do everything in batches. I do this so I can loop through 13 reports all pointing to one certain group of persons.
3) Works as a script out of the box and you don't have to change the format of your code.
4) Output. In R Notebooks I can output to HTML, PDF, Word/Libre Office or a dozen other formats with one line of code. I can have it in all formats at once. Because it all in one R Markdown file.
R notebooks keep all that HTML and Javascript in a separate file. You can choose to check that file into git if you want to version the output, but if all you care about is versioning the code, it's just a plain text R Markdown file.
that's interesting. what file is this and where is it kept?
so if i want to send my notebook to someone and include my results, i have to send two files? or is there one file per output, per directory, or per user?
If you want to save a plot you actually have to put the writing of the plot in the code. It would save as a image like png or svg. If your using the Notebook to share then they should just run the code on their side. If you want to make a report of it you just add one line of code and it will save a PDF/Word/Slide/etc for you in the present working directory.
Sharing the Notebook for them to reproduce your results is just one text file of the RMarkdown file.
git just backs up the source files not the output of the scripts. You could have a images folder and have git upload the graphics but I personally don't do that.
Ipython Notebooks is called Jupyter now, and it supports a bunch of languages in addition to Julia, Python and R (thus the Jupyter name). R Notebooks looks like a variation, but less of a REPL approach, perhaps.
As others have pointed out, revision control. That said, Jupyter supports more languages than R Notebooks.
For the best of both worlds, org-mode takes the revisionable approach of R Notebooks, but supports just about any language you could want. Org-mode simply requires turning on inline preview to duplicate the functionality of R notebooks.
Also, org-mode as a markup format supports some important features such as cross-references that are unsupported by RMarkdown.
Org-mode is the oldest of these three notebooks, yet is the most full-featured. If anything, the fact that you can do so very, very much more with org-mode is probably why it's the least popular. That and being tied to emacs in the same way that R notebooks is tied to RStudio.
Nevertheless, I have to wonder if we all wouldn't have been better off building a non-emacs implementation of org-mode rather than Jupyter and R Notebooks.
Native to the RStudio development toolkit. Seamless integration to R projects. I believe this is meant to improve R development output and presentation.
While not huge, they can be previewed in RStudio (not sure if IPN/Jupyter can be) but generally it's not a bad idea to have all the tooling from the same language crowd (imo). Worst case it's an extra alternative to the excellent IPN/Jupyter.
I've used RStudio more and more for my "quick check stats" like quickly calculating interrater reliability or whatever pops up (I only know the basics of R). As such I can totally see myself quickly sharing things with R Notebooks.
For everything that requires "plumbing" and/or actually uses stats in software I gravitate towards the Python toolchain. Might not make sense but that's how I work. I've also noticed that RStudio is accessible enough to non programmers for the same quick checks I run (converting over some SPSS users...yay?!).
Language wise you can use the following in knitr:
We can use any languages in knitr, including but not limited to R. Here are some simple demos with Python, Awk, Ruby, Haskell, Bash, Perl, Graphviz, TikZ, SAS, Scala, and CoffeeScript, etc:
Also glad Python works for you and it is an awesome choice. I would just recommend looking at dplyr tutorial for the "plumbing." you might keep to your Python but this is an awesome workflow. https://cran.rstudio.com/web/packages/dplyr/vignettes/introd...
One drawback worth mentioning is that while all R chunks in a notebook share the same environment, non-R chunks do not. This means that if the first e.g. python chunk creates a variable `x`, the next python chunk will not be able to use it. Jupyter notebooks don't have this issue.
Any process can connect to a running Jupyter kernel, just like IPython's IDE support. Emacs uses this to inspect variables and provide autocomplete suggestions for variables inside a running Jupyter notebook, for example.
One of the benefits R studio has over the Jupyter notebooks is the global environment view. It makes it very easy to look at your data and go through it.
The ability to visualize your code and the output, with the intermediary steps all along if you want or need, is extremely helpful.
And I can just email the html notebook itself to anyone who needs to check the steps: the notebook easily outputs to HTML (which I can save to PDF on a webbrowser if I don't want to output to PDF directly, which requires installing gigabytes of latex files and fonts)
I believe research should be done this way: fully reproductible and transparent, text, methods and data, all included in one file.
