4 ms·

If you ever have used an R Notebook written in R-Markdown, then its pretty easy to see why Jupyter Notebooks putting everything in JSON is just... infuriatingly

If you ever have used an R Notebook written in R-Markdown, then its pretty easy to see why Jupyter Notebooks putting everything in JSON is just... infuriatingly wrong-headed. In an R Notebook, I can see my code, I can see my text, everything is exceedingly simple to understand, and I can edit it in any of the fantastic text editors out there (Jupyter's editor is not among them)

optimuspaul 8y ago
YES! R Notebook is so much better in my opinion than Jupyter. I definitely prefer to work with a simple format verses JSON for this kind of work.
- narwally 8y ago
  Agreed, but I'm coming from the org-mode side of things. Have you ever tried git diff on a JSON file? It's not always pretty.
celrod 8y ago
RStudio is also my favorite editor. All my work is data science / stats related, where I like the workflow of writing/modifying code in a .R (or .py) file, and being able to quickly experiment by running chunks in a REPL with Ctrl + Enter. R and Python are supported. No Julia, unfortunately. VS Code and Atom support similar workflows with Julia. However, the Julia Language server in VS Code is extremely unstable and I regularly lose LaTeX completions. The REPL in Atom is mind boggling laggy and slow to the point that it is much less frustrating to copy and paste code into a REPL running in your favorite terminal emulator.
- mlevental 8y ago
  r studio supports python? does it completion and stuff like that?
  - celrod 8y ago
    It uses reticulate for REPL support, and has basic Python completions and snippets. However, it doesn't seem to complete variable names. Eg, if I defined "foobar", it won't let me tab-complete that later when I start typing "foo".
  - jonnycomputer 8y ago
    You can use R Studio to execute the code, and you're preferred editor to do the editing, if you like.
    - acosmism 8y ago
      try https://gryd.us https://gryd.us
- 3rdAccount 8y ago
  Is that atom's fault or just the Julia REPL's fault? I use the REPL directly on Windows and it seems to be really slow as it will take something like "using JuMP" and precompile the module which takes time.
  - celrod 8y ago
    I think it is Juno (the Julia package for Atom)'s fault. Atom is fine on its own, as is the Julia REPL after compilation. I just looked through Julia's settings tab in Atom, and saw the option "Fallback Renderer" with the note "Enable this if you're experiencing slowdowns in the built-in terminals." It was disabled by default, so I've just enabled it. Subjectively, I think it feels fine now. Longer use will tell, but I suspect I was just running into a known issue some setups run into, and they already provided the workaround. EDIT: Comparing running some code in Atom's terminal and a REPL running in the GNOME Terminal, the regular REPL still feels notably snappier -- even though I'm `using OhMyREPL`, which makes the REPL a bit less responsive. I'd say Atom feels acceptable (and definitely not "mind boggling laggy" right now), and shift/ctrl + enter more convenient than switching tabs. So I will stick with it (for Julia). More time shall tell.
    - 3rdAccount 8y ago
      I wonder if Windows is slower. It isn't terrible, but waiting 8 seconds after typing in "using JuMP" is kind of long.
joshuamorton 8y ago
As a result of the serialize-to-json approach, jupyter supports R, python, scala, go, lua, bash, julia, and haskell, among others. Its accessible to a much wider range of programmers, at the cost of version control being a bit weirder.
- jonnycomputer 8y ago
  It might be the case that serializing to json facilitates support for multiple languages, though I wonder how. With the reticulate package in R Markdown you can run python chunks, by putting, e.g. ```{python} for i in range(1:10): print("{}:{}".format(i, i*i)) # etc ``` And in emacs org-mode you can: #+begin_src python for i in range(1:10): print("{}:{}".format(i, i*i)) #+end_src Language support in org-mode is pretty comprehensive, afaik. I do not know the details of the implementations behind these, but my own source code is plain and simple unserialized text, and that means a lot to me.
  - joshuamorton 8y ago
    Ah, actually it looks like I'm somewhat mistaken. R Markdown supports other languages as well. I think the real difference is that it doesn't look like R Markdown supports partial evaluation. By that I mean that that to share the r-markdown doc it appears that you need to rerun the whole thing. It does some tricks to do concurrent visualization, but to actually share the doc you have to rerun all the R/python from scratch. In jupyter OTOH, if I have a long running ML pipeline as part of my doc, I can render without rerunning the pipeline.
    - huac 8y ago
      You can cache the results of an rmd cell, and you can also share the rendered version of the doc first. You're right that there's a higher emphasis on "run the whole thing," and I think that that's a conscious (and acceptable) design choice vs not being sure that the shared doc will run as provided.
      - 8y ago
kortex 8y ago
The main reason for json, I believe, is that the Jupyter client is separate from the backend. It's actually pretty trivial to run the engine on a beefy box while interacting on a light laptop (on the same subnet). With Jupyter Lab and some fiddling, you can put the server anywhere. It's also trivial to export notebooks to .py files. That said, my goodness do notebooks wreak havoc on git. I hope this in particular gets fixed as popularity grows.
- vhhn 8y ago
  RStudio has a server mode as well
- enriquto 8y ago
  > It's also trivial to export notebooks to .py files. But this is useless if you cannot edit those py files and obtain notebooks from them.
- PurpleRamen 8y ago
  Having a proper server available is even more reason to use a proper fileformat. The client doesn't care what the server handles and the server doesn't need to send raw datastructures directly from the storage. Actually, fixing the fileformat-mess should be very simple. Just change the file-load/save-functions. Use a folder-structure with every cell being a seperate file. Or switch to XML. Or make a generic interface and allow to save in whatever the people want. Saving notebooks in Mongodb or some SQL-Database seems like a good goal for dedicated services.
baldfat 8y ago
Here is a link to why the R Notebook is a much better format for doing science. I also prefer it since I use GIT. https://rviews.rstudio.com/2017/03/15/why-i-love-r-notebooks/ https://rviews.rstudio.com/2017/03/15/why-i-love-r-notebooks... This is the reason why it is great. > 1) Plain text representation

optimuspaul 8y ago

YES! R Notebook is so much better in my opinion than Jupyter. I definitely prefer to work with a simple format verses JSON for this kind of work.

narwally 8y ago
Agreed, but I'm coming from the org-mode side of things. Have you ever tried git diff on a JSON file? It's not always pretty.

celrod 8y ago

RStudio is also my favorite editor. All my work is data science / stats related, where I like the workflow of writing/modifying code in a .R (or .py) file, and being able to quickly experiment by running chunks in a REPL with Ctrl + Enter. R and Python are supported. No Julia, unfortunately. VS Code and Atom support similar workflows with Julia. However, the Julia Language server in VS Code is extremely unstable and I regularly lose LaTeX completions. The REPL in Atom is mind boggling laggy and slow to the point that it is much less frustrating to copy and paste code into a REPL running in your favorite terminal emulator.

mlevental 8y ago
r studio supports python? does it completion and stuff like that?
- celrod 8y ago
  It uses reticulate for REPL support, and has basic Python completions and snippets. However, it doesn't seem to complete variable names. Eg, if I defined "foobar", it won't let me tab-complete that later when I start typing "foo".
- jonnycomputer 8y ago
  You can use R Studio to execute the code, and you're preferred editor to do the editing, if you like.
  - acosmism 8y ago
    try https://gryd.us https://gryd.us
3rdAccount 8y ago
Is that atom's fault or just the Julia REPL's fault? I use the REPL directly on Windows and it seems to be really slow as it will take something like "using JuMP" and precompile the module which takes time.
- celrod 8y ago
  I think it is Juno (the Julia package for Atom)'s fault. Atom is fine on its own, as is the Julia REPL after compilation. I just looked through Julia's settings tab in Atom, and saw the option "Fallback Renderer" with the note "Enable this if you're experiencing slowdowns in the built-in terminals." It was disabled by default, so I've just enabled it. Subjectively, I think it feels fine now. Longer use will tell, but I suspect I was just running into a known issue some setups run into, and they already provided the workaround. EDIT: Comparing running some code in Atom's terminal and a REPL running in the GNOME Terminal, the regular REPL still feels notably snappier -- even though I'm `using OhMyREPL`, which makes the REPL a bit less responsive. I'd say Atom feels acceptable (and definitely not "mind boggling laggy" right now), and shift/ctrl + enter more convenient than switching tabs. So I will stick with it (for Julia). More time shall tell.
  - 3rdAccount 8y ago
    I wonder if Windows is slower. It isn't terrible, but waiting 8 seconds after typing in "using JuMP" is kind of long.

joshuamorton 8y ago

As a result of the serialize-to-json approach, jupyter supports R, python, scala, go, lua, bash, julia, and haskell, among others. Its accessible to a much wider range of programmers, at the cost of version control being a bit weirder.

jonnycomputer 8y ago
It might be the case that serializing to json facilitates support for multiple languages, though I wonder how. With the reticulate package in R Markdown you can run python chunks, by putting, e.g. ```{python} for i in range(1:10): print("{}:{}".format(i, i*i)) # etc ``` And in emacs org-mode you can: #+begin_src python for i in range(1:10): print("{}:{}".format(i, i*i)) #+end_src Language support in org-mode is pretty comprehensive, afaik. I do not know the details of the implementations behind these, but my own source code is plain and simple unserialized text, and that means a lot to me.
- joshuamorton 8y ago
  Ah, actually it looks like I'm somewhat mistaken. R Markdown supports other languages as well. I think the real difference is that it doesn't look like R Markdown supports partial evaluation. By that I mean that that to share the r-markdown doc it appears that you need to rerun the whole thing. It does some tricks to do concurrent visualization, but to actually share the doc you have to rerun all the R/python from scratch. In jupyter OTOH, if I have a long running ML pipeline as part of my doc, I can render without rerunning the pipeline.
  - huac 8y ago
    You can cache the results of an rmd cell, and you can also share the rendered version of the doc first. You're right that there's a higher emphasis on "run the whole thing," and I think that that's a conscious (and acceptable) design choice vs not being sure that the shared doc will run as provided.
    - 8y ago

kortex 8y ago

The main reason for json, I believe, is that the Jupyter client is separate from the backend. It's actually pretty trivial to run the engine on a beefy box while interacting on a light laptop (on the same subnet). With Jupyter Lab and some fiddling, you can put the server anywhere. It's also trivial to export notebooks to .py files. That said, my goodness do notebooks wreak havoc on git. I hope this in particular gets fixed as popularity grows.

vhhn 8y ago
RStudio has a server mode as well
enriquto 8y ago
> It's also trivial to export notebooks to .py files. But this is useless if you cannot edit those py files and obtain notebooks from them.
PurpleRamen 8y ago
Having a proper server available is even more reason to use a proper fileformat. The client doesn't care what the server handles and the server doesn't need to send raw datastructures directly from the storage. Actually, fixing the fileformat-mess should be very simple. Just change the file-load/save-functions. Use a folder-structure with every cell being a seperate file. Or switch to XML. Or make a generic interface and allow to save in whatever the people want. Saving notebooks in Mongodb or some SQL-Database seems like a good goal for dedicated services.

baldfat 8y ago

Here is a link to why the R Notebook is a much better format for doing science. I also prefer it since I use GIT. https://rviews.rstudio.com/2017/03/15/why-i-love-r-notebooks/ https://rviews.rstudio.com/2017/03/15/why-i-love-r-notebooks... This is the reason why it is great. > 1) Plain text representation