We have solved this problem by providing 2-way sync between notebooks and libraries, using a system called nbdev:
Not sure when the final version will be released. Main thing we need to do is cleaning up the docs.
The main problem with emacs org-mode is that users probably need to use emacs, and lots of people have their own editor preferences, and while some have org-mode-alike's, they aren't as fully capable as emacs org-mode. Which is what Jupyter addresses by making the interface more accessible/editable to all.
That said, I think one of the most important factors that the linear notebook flow encourages is a focus on reproducibility, whether it's Jupyter or Org-Mode. I feel like overcomplicating the dev environment would make the much harder and would at least need to be planned for.
I accidentally discovered this after exporting a jupyter notebook to python and opening it in vscode.
Still just merging the notebooks into the editor is a big step. :-)
This issue is super annoying. Notebook's _force_ you into that linear style -- which then packages up your code in a form that can't compose with anything ... Its not even a limitation of the notebook file format as if often thought -- its simply the case that notebook's work best when the majority of code in the notebook is in the same scope -- otherwise you can't interactively inspect intermediate variables ...
I was helping a friend of mine with some data science tasks and made a little library to restore some ability to compose a notebook written in that linear style into larger programs ...
https://github.com/breathe/NotebookScripter
Its relatively easy to take a notebook written normally, define a few parameters for it that can be configured externally, and turn that notebook into a callable function ...
I really think that the various notebook implementation's (jupyter, swift playgrounds) -- _need_ to add some sort of parameterization model to the notebook concept. Its not that hard to come up with a transformation that allows one to (1) work interactively in a notebook which has its parameters inferred from defaults (2) exposes a callable interface to that notebook that allows the caller to supply new values for parameters
A Notebook <-> function transformation is really all that is needed to create a real-programming model for Notebook's which would let one compose notebook's into larger programs while still writing the notebooks themselves in a way that's useful for data exploration ...
Going both ways Notebook <-> function and function <-> Notebook would be such a nice general purpose development feature... I'd love to take any function in a swift project and be able to interactively develop the function body in a 'playground like environment'. All that's required would be to supply values for the function's arguments -- and then there is no reason (aside from the limitations of the existing tools) why you couldn't compile the function into a form that supported a 'playground-like' experience for working on the function body.
I'm dreaming about something like Emacs Slime[0] for other languages (that aren't Common Lisp) where you can write code, evaluate it in the editor, switch to the REPL and test it, recompile while debugging.... etc. [1]
And the most similar tool of the other languages... is basically jupyter-notebook. There is no such tool for interactive development except with the bare-bone REPL in the shell.
[0] https://common-lisp.net/project/slime/
[1] https://www.youtube.com/watch?v=_B_4vhsmRRI, https://www.youtube.com/watch?v=sBcPNr1CKKw,
For literate programming, the Clojure/Clojurescript ecosystem keeps bringing up fascinating environments (in addition to CIDER+Org-mode and Clojupyter).
https://github.com/metasoarous/oz
https://github.com/jsa-aerial/saite
https://github.com/pink-gorilla/gorilla-notebook
are all actively developed and worth following, and they are all rather innovative in the ideas they bring to the table.
For polyglot reproducible literate programming, there is also https://nextjournal.com (implemented in Clojure/Clojurescript).
I think there should be a better integration between editors & REPLs, something like Common Lisp & Emacs SLIME. SLIME queries a server running on Common Lisp to incrementally compile & evaluate code from the editor (like LSP, but not autocomplete queries but evaluation queries). I hope the LSP protocol gains ability to evaluate code for languages with REPLs, it would be awesome if it allows interactive development in multiple editors & multiple languages (like how LSP is facilitating autocomplete).