for the reasons you mentioned (Among others) I think Neptune.jl should get more attention.
It should be the sequential form of Pluto.jl with reactivity (Adding LaTeX reactivity should be a feature added to both).
Once the community keeps parity between Neptune.jl and Pluto.jl I think Neptune.jl will be come the de factor Jupyter Notebook of Julia with the advantages of being version control friendly to generate standard notes while Pluto.jl will become the standard way to generate reactive HTML pages with Julia.
Being sequential and non reactive has many advantages when dealing with large data sets and heavy computations. Hence it is a good complementary to Pluto.jl.
As a wrapup, there are different types of notebooks w.r.t. reactivity and cell order:
No reactivity, cells are executed manually. Technically, cell order does not matter but practically cells should be in execution order (or the latter be explicitly documented) so that notebooks are reproducable. Examples: Jupyter, Neptune.jl
Reactive notebooks, where cells must be in execution order. This is the request of @kapple if I understand it correctly.
Reactive notebooks where cell order in the notebook does not matter. Examples: Observable (JS), Pluto.jl.
Type 2. in Pluto is already possible, but there are no tools available for bringing the cells into execution order. The information however is already in the frontend (https://github.com/fonsp/Pluto.jl/pull/891 ).
One idea would be to extend https://github.com/fonsp/Pluto.jl/pull/1144 so that pressing Ctrl shows the execution order for all cells. This would allow the users to re-order them if needed.
In general due to the sparsity of developer resources it would be better to concentrate on a few products (I would say Jupyter and Pluto) than forking if there is a way to avoid it.
The only thing I’ll correct is, I was mainly (and unclearly) requesting/wishing for a notebook that would be reactive for mathematics and programming. I suggested cells be in execution order, i.e. top-down execution, because I thought it might assist with reactivity for the mathematics. However, others have clarified that it would not necessarily solve the issue, or might reduce productivity significantly. Starting anew or like you said, forking, is less efficient for development.
As a little criticism of Pluto, I’ll also repeat that in the plethora of presentations, lectures, and courses that use Pluto notebooks, pretty much all of them are presented/read from the top, downwards.
Even if you use the notebook from top downwards, it is good to have the option to move parts which are not required for didactical purposes (like utility functions) to the Appendix.
Yes, agreed. Which is similar to MATLAB scripts having script-defined function blocks at the end of the script.
And even in LaTeX docs, it’s nice to have an appendix that calls for the code source files and prints it all nicely.
I do this too, it’s just that there’s some instances where it would be beneficial to have the top-down evaluation order. I’m not against Pluto’s cell evaluation order, I’m saying it shouldn’t be the only option.
I just watched a quick tour of TeXmacs. Although I prefer the more programmatic typesetting experience, it’s quite nice. I love Pluto because its use of Julia Strings is what brings out the documentation texting experience, and you can programmatically play with the strings.
If I understand correctly from this conversation, TeXmacs has already demonstrated executing Julia as a kernel through a Jupyter plugin, but now you’re/they’re looking at developing a TeXmacs plugin that calls Julia directly? If so, what will be the difference? Performance?
I’ve been thinking about your solution that you mention is flawed/suboptimal, i.e.
This is essentially what Weave.jl does anyway. Each call of weave(filename) during document development essentially starts anew, and having a top-down evaluation in Pluto would be a step above what Weave does.