Same question, but s/running repl in an Emacs buffer/authoring in org-babel/ - I have a hard time seeing Jupyter and friends as anything other than a subset of what people have been using org-babel to do for years, and I'm not really sure whether that's an accurate perception or not.
Thank you for the babel reference, it looks interesting. From what I can tell, it's pretty similar. In a notebook I'm directly editing the code and seeing the results immediately, instead of switching back and forth between emacs and a browser window. That looks like a pretty big win for interactive development. Is there any babel feature that you think is missing in Jupyter?
Babel does the same thing; you just press Control-C twice while the cursor is in a code block, and it's evaluated and the results inserted immediately below the code block. (If there are already results there, they're replaced by default, but you can opt to have new ones appended instead.) It's no less interactive than Jupyter; it's just interactive in the paradigm of an Emacs buffer instead of a browser window.
A major feature Babel offers, which Jupyter doesn't seem to, is passing data among code blocks in different languages. Any language Babel supports [1] can receive results from any other in the receiving language's native idiom, so there's no need to marshal temporary files or what-have-you in order to exchange data among blocks - Babel takes care of that for you. In a case where multiple transformations are necessary to get from source data to results, this makes it very easy to express each in a language well suited to it, without having to spend a bunch of time and mental energy on menial file shuffling.
The same is true for most other representations of data that Org mode supports. In particular, Org tables, which themselves have many features of spreadsheets, can be sourced in code blocks in the same way as the results of other code blocks, and a code block can generate an Org table as a result. These tables can be imported and exported as CSV, too. My work is professional rather than academic, but I can imagine a lot of cases in which this capability would be useful in the latter context, and Jupyter doesn't seem to offer it. (It's hard to tell, because Jupyter's documentation seems pretty thin overall - not something which can be said of Org mode.)
On the whole, Jupyter looks like a pretty nifty tool, and one which would be accessible to people who don't already use Emacs. I'm not sure how I would feel about recommending Emacs to someone just for Org mode, although I've heard several people say they picked up Emacs for precisely that reason and have stuck with it. But, if you already use Emacs and don't have contextual reasons (such as everyone else around you using Jupyter) to choose one tool over another, I wouldn't hesitate to recommend investigating Org mode first, because it is very nearly a strict superset of Jupyter. (It'll be a few years before you can easily embed a video in an Emacs buffer; right now you'd need to use a pre-release version with some extra compile options.)
That sounds really nice, thank you for taking the time to write all this. I do use Emacs for editing, and I miss all the features SLIME offered for Common Lisp. Unfortunately, I'm using Julia now, and while the language is really getting there, tooling support is minimal outside of Jupyter and Atom, so I wouldn't bet on Babel.
I should learn org-mode though. I've heard so much praise for it!
I have been using Julia in emacs, primarily using ESS [1] and ob-julia [2] (org babel julia package). It is relatively well integrated with some basic auto-complete features and nice org-babel integration (as good as python or r).
As an org-babeler myself, and someone who has also used RMarkdown and Jupyter notebooks, I feel like these newcomers are quite underpowered compared to Org. Not to mention that mixing languages in a single doc is not possible / cumbersome with the others.
I do recognize, however, that being tied to emacs (the only complete implementation of org-mode / org-Babel today) is a liability. I wonder if some smart person will figure out a portable implementation in something else. Of course, it won't match the flexibility or extensibility of emacs, but perhaps it can still surpass Jupyter / RMarkdown.
I mention RMarkdown together with Jupyter simply because org-mode / org-Babel nearly addresses both the dynamic notebook use case as well as the document publishing use case (including nice academic feature like cross-references, which aren't supported in Markdown).