Jupyter is the main reason I come back to writing Python. I really wish there was a Jupyter environment for any language. I'm aware there exist kernels for other languages, but many of them are unstable, slow, outdated, or miss important features. I have tried multiple, and every time I come back to Python, not because I want to write Python, but because Jupyter works so well.
R and Julia’s aren’t good? They’re in the name, so I would have thought support would continue to be strong. I like Julia’s Pluto and the reactive style more than Jupyter anyway.
Every year, most JuliaCon workshops are presented via Jupyter notebooks; the Julia support is pretty good and has remained stable for a long while.
Some of the unofficial extensions like `code_prettify` don't work for Julia kernels, but at least for my usage, I've never felt the need for such tools in a Jupyter notebook.
IJulia is falling behind. If you look at github activity, it has 1 commit in past month. Compared to 9 authors and 39 commits in past month for IPython. IJulia issues are piling up.
Anaconda foundation does really great marketing, outreach, advocacy, education...it's a good first place for data scientists to land. But actually installing and using Conda is always annoying. I wind up doing everything with pip and venv, because pip jsut works.
On the topic of Conda and Jupyter, install jupyter via a virtualenv pip installation, and then to use a specific conda kernel, load your conda environment in another shell, and install IRkernel in that environment. As long as you install to the main Jupyer prefix, jupyter should see the new conda kernel.
You can do this for as many kernels/conda envs as you need
And from whatever source, I knew Mathematica notebooks had looked how they had /at least/ since the mid 90s. (My Mathematica days were college, and I did not spend much time contemplating the history of my tooling)
From elsewhere in the comments, it sounds like iPython->jupyter wasn't just a rebranding, as I assumed it was at the time.
Cannot see how. Smalltalk and Lisp basis are allowing modification of the environment itself even while running. Jupyter cannot do that and the notebook interface (basically originating from Mathematica) isn't suitable, or even has goal to be, for generic programming.
>"Symbolics Lisp Machine demo", special focus on 5 minute onwards.
To provide more information since video description lacks, this is OpenGenera a Lisp Machine OS designed to also run hosted on Unix systems. This specific version (seeing it uses jpeg) should be from mid- to late- 90s. Had tried some version but didn't remembered being able to have graphics on REPL.
Yes, that's basically how Jupyter console works. But will still argue that the Jupyter model is such weaker version of this that can hardly be called a derivative. Listener isn't only limited to being used like an isolated shell but can be attached to any part of the environment. (And this introspection is core to Lisp and Smalltalks environments.)
>Mathematica was inspired from Lisp
The language Wolfram, yes. The cell-based notebook interface was new. But similar to previous is a more limited version of what you had available; specifically interchanging text and code in Zmacs. Something that was also an advantage (easier of reason with) for what Mathematica was used for.
I’ve been messing around with Microsoft’s Polyglot Notebooks which looks pretty interesting. Caveat: I’ve not used Jupyter and that was my first experience of notebooks.
#+begin_src R :colnames yes
words <- tolower(scan("intro.org", what="", na.strings=c("|",":")))
t(sort(table(words[nchar(words) > 3]), decreasing=TRUE)[1:10])
#+end_src
Is it possible to have minimal syntax for these code blocks? Markdown is nice because it looks clean, and the syntax does not get in the way. Markdown codeblocks are
You could put all the common headers in a property drawer of top-level heading, and all child source code blocks inside that heading will inherit them.
* Notebook
:PROPERTIES:
:header-args:R: :colnames yes
:END:
#+begin_src R
words <- tolower(scan("intro.org", what="", na.strings=c("|",":")))
t(sort(table(words[nchar(words) > 3]), decreasing=TRUE)[1:10])
#+end_src
As for making the block delimiter look different, there are various ways of making the text display differently from the actual text. For example, you could use the built-in `prettify-symbol-mode` with this config:
You could, for example, use Python which I believe would be clearer than this R mess ;-)
Joking aside though, if src block header (which can have a lot of options set up including specifying environment, tangling other block variable of setting totally separate interpreter version) is huge problem there are plethora of presentation customization.
Emacs allows customizing face and more. Org-modern [1], for example, uses font signatures and fringes for making it less “technical”
I'd expect there will be a lot of new solutions coming soon, because Polymode [0] seemingly solves the hard problem the org-babel struggles against. The immiscible major modes, and all that extra syntax and buffer-switching that org-babel needs to work around that problem.
Creating something in the scope of Jupiter is not trivial.
You do have a few nodejs/typescript/javascript kernels that work fine, so I don't see the point for rewriting Jupiter in node specifically for any reason.
In any case, maybe creating something for the browser only is easier because JS is native, but still I wouldn't call it "pretty trivial". For this use case (and more) you have projects like
You're overlooking the power that a preconfigured REPL with a persisted canvas integrated with markdown brings to the table.
It is a really powerful toolset, and building your own environment from separate parts is not trivial; so having it preconfigured in a standard way that others can reuse is no small matter.
I prefer online notebooks with a functional-reactive behaviour, such as ObservableHQ (which is JavaScript-based, rather than python); but Jupyter was the first popular one, so it hit hard.
You might be misinterpreting me here. I’m not dismissing the utility. Quite the contrary, I’m saying that it wouldn’t be terribly groundbreaking or challenging to implement compared to some other green field problem. Although at this point I do agree that trivial was the wrong word.
Observable looks cool, but it doesn’t seem portable. It really bums me out that so much of the JS ecosystem is so sheerly commercial in this way. Sometimes I don’t understand why this is like this compared to the Python ecosystem. It’s not that I’m cheap either. I’ll happily pay for things that are properly monetized and provide a good value for my time. This doesn’t seem like it.
You might like tslab. It allows you to have the full notebook experience with either JavaScript or Typescript. My day to day is data analysis. JS/TS runs circles around pandas and you aren’t constrained to vectorized operations. If there were a suitable replacement for matplotlib I would leave python behind altogether.
What is the experience like using a compiled language in such interactive environment? Like you cannot for example do something in one cell and utilize the result to another, or can you?
