> 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.
Fair counterpoint, although when I wrote that I was more referring to the HTML knitting (via knitr). Also, there's a few very-new VS Code plugins for R Markdown which look very very interesting. (https://marketplace.visualstudio.com/items?itemName=neuron.n...)
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.
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.
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”.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.