50 comments

[ 92.2 ms ] story [ 4742 ms ] thread
Bit of a typo in the title. Original: Advantages of Using R Notebooks For Data Analysis Instead of Jupyter Notebooks
R notebooks behave similarly to org-mode, albeit with fewer supported languages and a few less options for controlling execution and value passing between code blocks. Org-mode is the oldest and most powerful environment of this sort that I know of.

That said, for new users, I think R Notebooks are less daunting than Emacs + org-mode.

Like most things associated with RStudio and the Tidyverse, I feel that they’ve really done their homework. Even if org-mode does more, I feel it’s pretty evident that R Notebooks at least made an effort to understand org-mode’s prior art.

I think it's likely R was inspired more by Mathematica's venerable notebook interface.
It was obviously inspired by many different things but the most direct genealogy is WEB [1] → noweb → Sweave → Knitr → R Markdown → R Notebooks.

Mathematica’s notebook interface in turn was almost certainly also inspired (directly or indirectly) by WEB, given that this was the first literate programming tool ever created.

[1] https://en.wikipedia.org/wiki/WEB

RE python in Rmarkdown being limited...

> The Python session ends after the cell executes, making it unhelpful for tasks other than ad hoc scripts.

This isn't the case anymore thanks to the reticulate library.

https://blog.rstudio.com/2018/03/26/reticulate-r-interface-t...

Reticulate was a major improvement in the data science workflow. We now have full interoperability between R, Python, and Julia (or Scala if you're on Spark). The ability to mix languages is really valuable.
What would be the equivalent package for Julia?
PyCall.jl can call Python from Julia. On the downside, it has a lot of problems and there doesn't seem to be enough dev effort to match.
Is there an equivalent library for Julia?
OP here:

reticulate isn't native to R Studio yet (it's in the insider build), but will be interesting to see what happens with adoption then.

It’s just that RStudio’s vim support is so extremely bad, compared to VSCode or even the Jupyter Notebook vim plug-in. I guess this won’t bother you if you don’t have a developer background, but I find that editing code in RStudio is a real pain.

I wish I could use RStudio with the exact same keybindings and vim behavior as Jupyter in the browser. That alone would make things bearable. Like the exact same keys for cell execution, adding new cells, etc. Call it “Jupyter mode”.

Also vim editing is restricted to editor window in the current session. So you can't paste from registers in console or in other RStudio sessions.

But its still much better experience to use RStudio markdown than Jupyter for me.

(comment deleted)
* You get enjoy a language with incompatible interfaces for every single data structure.

* Write-only language ensures your ideas are difficult to steal

That sounds kind of ..uhmm.. incoherent. Care to elaborate?
If you’ve used both R and another, more reasonable language for any length of time, it’s perfectly coherent.
In the Tidyverse everything in R is perfectly logical and coherent. What would you consider to be a “reasonable” language then?
One where it was not necessary to specially create a ‘tidy’ version of everything to escape the horrific mess that exists by default
OK, I see. The debate is gradually coming to the pitchforks and torches phase. Tons of adjectives and still zero meaningful input. I insist on explaining what the "horrific mess" part is about.
Your language was perfect the day it was created was it? R and it’s ecosystem stand head and shoulders above the rest.
It would help if you said explicitly what language you think is better in this respect. Having Data Frames in Python at all requires importing Pandas afaik, so criticizing R for requiring an extra data-manipulation package wouldn't make sense from a Python perspective.
The point is not that you have to import a package, but whether by default package layouts and interop make sense. Notably, python scientific libraries build on a set of common foundations and apis (numpy, pandas etc). Additions to the ecosystem aim to build on familiar apis irrespective of implementation details (e.g dask). Python’s heavy use of namespaces makes organising a working environment simple, while it’s focus on consistent style and naming conventions means that code from different sources will look familiar. R meanwhile uses a global namespace (with at least two ways of loading libraries into it) so requiring more than a few extra libraries risks name collisions. Thus the need to create another ‘tidy’ library to fix a fundamental limitation of the language.
> R meanwhile uses a global namespace

This is just plain wrong.

Base R is also perfectly logical and coherent. If anything, it's so coherent for statistics work that it makes non-statistics work harder than it should be. For a 30-year old language that started life as a statistics package, that's pretty good.

R is no harder to read than C IMO, even badly-written R without spaces, indentation, proper line breaks, etc.

I'm using both R and Python on a daily basis (plus -- occasionally -- Clojure, Java and CL). Still, I don't understand what you mean.
(comment deleted)
Are you complaining about R or R Markdown? Because neither assertion is true for either language.
Working in RMarkdown it is super-easy to generate a publishable document from your research. Whereas there is still no good Jupyter—>PDF solution.
What's wrong with nbconvert?
It’s fine if you just want to show something to someone who for whatever reason can’t run the notebook themselves, but it’s not up to producing a “formal” document. Maybe in a few years it might be.
In theory, because you can access LaTeX features from an R Notebook, you could even write an entire manuscript with it, although I don't know if anyone has.
I’ve moved to Orgmode Babel for all my notebook needs. Work straight out of emacs, exports to many formats, literate programming, supports dozens of languages.

Previously used R notebooks exclusively for all the benefits author mentioned.

The article claims that

> R Notebooks can only be created and edited in RStudio

Luckily, this is wrong. Since R Notebooks are simply R Markdown, they can be edited with any editor (although the integration is obviously lost). This is, in fact, one of its decisive advantages over Jupyter Notebooks: most of the other issues mentioned in the article are solvable, whereas this issue fundamentally isn’t.

But the nice interactivity of it is only in RStudio iirc, which is a major selling point.
Yep, the RStudio integration is very nice. However, there are other ways of authoring R Notebooks that also allow interactivity, and the only thing that’s missing then is having output inline inside the editable document. Apart from that, if you for example use Nvim-R or ESS, you can write R Markdown, execute chunks selectively, and get a visual, interactive representation of the results in real time that way. And once the document is done, a single press of a button will render the resulting Markdown/HTML/PDF document.
After I used ESS with Emacs starting many years ago, I haven't opened RStudio. I know RStudio is very very nice, and ESS is a very complete option too.
Primary disadvantage of using R Notebooks Instead of Jupyter Notebooks: Writing R instead of numpy / pandas python.
You can use Python in R Notebooks. It is not fully integrated with RStudio, but pertaining just the notebooks, it runs fine.
R's tidyverse, along with the numerous R packages/documentation developed and tested over a long period of time, are efficient too. Thankful to see both Python and R thrive.
Does anyone know why the ipython developers rejected solutions in which version control diffs were readable?