10 ms·

I think it would be cool to run the same analysis on the number of R Notebooks on Github and compare the two.

by KyleOS 7y ago

turingbike 7y ago
Aren't Jupyter notebooks R notebooks? Jupyter stands for "Julia, Python, R" I believe
- eoinmurray92 7y ago
  Yeah this is true but sometimes R notebooks also refers to R studio notebooks - https://rmarkdown.rstudio.com/lesson-10.html https://rmarkdown.rstudio.com/lesson-10.html
- jsilence 7y ago
  But the user is choosing a Jupyter Kernel upon creation and the code is run on either one of the available Kernels. No code mixing within one notebook at the current point.
  - hulahoof 7y ago
    I thought you could with apache toree? Maybe I misunderstand the project
- KyleOS 7y ago
  I think the file extension scraped on Github is only .ipynb, which is only python notebooks right?
  - rodonn 7y ago
    I think most people save under this extension even if they are using a different kernel (i.e. they are running R, Julia, Matlab, etc. code in the notebook).
    - eoinmurray92 7y ago
      Yeah so its mostly a split between Jupyter and R Studio - but Jupyter can mean different languages
randomfool 7y ago
I did this a while ago on a sampling of the dataset from https://bigquery.cloud.google.com/table/fh-bigquery:github_extracts.contents_ipynb?pli=1 https://bigquery.cloud.google.com/table/fh-bigquery:github_e..., Python is ~100x that of R. R users are mostly using RStudio.
localhost 7y ago
The R community has built an incredible competing tool in RStudio and RMarkdown. You could argue that the progress of Jupyter is being held back by its ties to JSON as the serialization format for notebooks (which enables, among other things, the ability to serialize notebook execution output into the .ipynb vs. RMarkdown which does not). So the fairer comparison would be to compare .rmd vs. .ipynb instead of looking at the kernelspecs in .ipynbs to see the distribution of R users. In my experience (I own the Azure Notebooks service at Microsoft), I see very little R usage - in the order of 1% of Python, similar to what other commenters on this thread have seen.
- claytonjy 7y ago
  Can you imagine how much headache would have been saved if Jupyter was basically Rmarkdown with a less R-specific extension and a more general backend? After years with R I've been doing a lot of python work lately and UGH it feel like JupyterLab is a decade behind Rmarkdown. We wouldn't need special viewers in our source control frontend, or git hooks + tools like jupytext, or in-between editor plugins (VSCode)! By not storing state with input and forcing top-to-bottom linear runs, I think the entire field of machine learning would be significantly more reproducible than it is now.
  - localhost 7y ago
    I totally agree with your sentiment. However, I also think that the popularity of Jupyter is largely due to the fact that it does appeal to a certain type of user. I do believe that we have room for more than one option. The work that we've done in interactive programming in the Python VS Code extension is one possible approach that folks have seemed to like, and that aligns with what you're saying. We're going to continue to explore that direction in addition to the Jupyter work that we're doing. Stay tuned!

I think it would be cool to run the same analysis on the number of R Notebooks on Github and compare the two.

by KyleOS 7y ago

I think it would be cool to run the same analysis on the number of R Notebooks on Github and compare the two.

turingbike 7y ago

Aren't Jupyter notebooks R notebooks? Jupyter stands for "Julia, Python, R" I believe

eoinmurray92 7y ago
Yeah this is true but sometimes R notebooks also refers to R studio notebooks - https://rmarkdown.rstudio.com/lesson-10.html https://rmarkdown.rstudio.com/lesson-10.html
jsilence 7y ago
But the user is choosing a Jupyter Kernel upon creation and the code is run on either one of the available Kernels. No code mixing within one notebook at the current point.
- hulahoof 7y ago
  I thought you could with apache toree? Maybe I misunderstand the project
KyleOS 7y ago
I think the file extension scraped on Github is only .ipynb, which is only python notebooks right?
- rodonn 7y ago
  I think most people save under this extension even if they are using a different kernel (i.e. they are running R, Julia, Matlab, etc. code in the notebook).
  - eoinmurray92 7y ago
    Yeah so its mostly a split between Jupyter and R Studio - but Jupyter can mean different languages

randomfool 7y ago

I did this a while ago on a sampling of the dataset from https://bigquery.cloud.google.com/table/fh-bigquery:github_extracts.contents_ipynb?pli=1 https://bigquery.cloud.google.com/table/fh-bigquery:github_e..., Python is ~100x that of R. R users are mostly using RStudio.

localhost 7y ago

The R community has built an incredible competing tool in RStudio and RMarkdown. You could argue that the progress of Jupyter is being held back by its ties to JSON as the serialization format for notebooks (which enables, among other things, the ability to serialize notebook execution output into the .ipynb vs. RMarkdown which does not). So the fairer comparison would be to compare .rmd vs. .ipynb instead of looking at the kernelspecs in .ipynbs to see the distribution of R users. In my experience (I own the Azure Notebooks service at Microsoft), I see very little R usage - in the order of 1% of Python, similar to what other commenters on this thread have seen.

claytonjy 7y ago
Can you imagine how much headache would have been saved if Jupyter was basically Rmarkdown with a less R-specific extension and a more general backend? After years with R I've been doing a lot of python work lately and UGH it feel like JupyterLab is a decade behind Rmarkdown. We wouldn't need special viewers in our source control frontend, or git hooks + tools like jupytext, or in-between editor plugins (VSCode)! By not storing state with input and forcing top-to-bottom linear runs, I think the entire field of machine learning would be significantly more reproducible than it is now.
- localhost 7y ago
  I totally agree with your sentiment. However, I also think that the popularity of Jupyter is largely due to the fact that it does appeal to a certain type of user. I do believe that we have room for more than one option. The work that we've done in interactive programming in the Python VS Code extension is one possible approach that folks have seemed to like, and that aligns with what you're saying. We're going to continue to explore that direction in addition to the Jupyter work that we're doing. Stay tuned!