On Fri, Oct 27, 2017 at 2:35 PM, Jose Gonzalez <[email protected]> wrote:
> I think it's also about building on Jupyter concepts as reproducible > literate programming platform, not just cloning its current functionality > I agree. Imo, a complete script is the ultimate in "reproducible". Fragments, as in Jupyter, less so. So Leo, with scripts composed of separate nodes, should be superior. I don't get why some scientists seem to prefer the fragmented approach. See it as an alternative to the JupyterLab application ( > https://channel9.msdn.com/Events/PyData/Seattle2017/BRK11), reusing the > same capabilities from Jupyter notebooks in terms of computing power > (multilanguage kernels), document integration (markdown + code cells in the > same entity), and ecosystem for all sort of data visualization (ipywidgets) > Reusing Jupyter's features, including kernels, appears to be challenging. I am investigating and will say more (in the projects area) when I know more. Things that "leopyter" could do better in my opinion would come from better > underlying data structures: > Leopyter: I like the term ;-) This is Leo's fundamental advantage over a flat list of cells. > - Hierarchical document structure would result in more organized > notebooks (example https://app.notablemind.org/tutorial/) > The challenge is integrating Leo's view with Jupyter's. This is where thinking in terms of .ipynb files is a good design exercise. For example, let's assume you use @others in a Leopyter script. How, exactly, is Leo (Leo's exporter) supposed to handle that @others? I don't think this is a gotcha, but it will require real invention on our part. - Causality: Establishing dependencies between cells execution does not > come out of the box in Jupyter, it requires extensions ( > https://github.com/stitchfix/nodebook or https://www.youtube.com/watch? > v=5MmXs6m3JcE) . This is essential for repetitivity and maybe leo graph > structure could accommodate this > To repeat, a complete script is the ultimate in reproducibility, and Leo has a huge advantage in this regard. - Links: being able to navigate across multiple notebooks in the same leo > document, which could be useful for keeping a knowledge base within a > notebook repository > Yes. > - Separate code from outputs. One of the main strengths for Leo, > combining code and results into the same document, is also one of its main > limitations. > I have been thinking of simulating some Jupyter features in much simpler prototypes. One such prototype would have execute-script "pipe" stdout to an @out node. It would likely take about 20 lines of code. The workflow for many people like me is to use the notebook first to "play > with a problem" while documenting/visualizing results and then mature the > code, isolating it to a function/library for broader use. Having results > and code in the same json document makes this process a little bit more > complicated, in many cases forcing the programmer to refactor the notebook > to extract the code (e.g. http://opiateforthemass.es/art > icles/why-i-dont-like-jupyter-fka-ipython-notebook/) Also, it you want to > keep your code under version control, you need to somehow strip out the > results before committing it (e.g. https://github.com/kynan/nbstripout). > I believe leo cloning and three way merging mechanism introduced for @clean > could probably help in separating notebooks into different physical store > files that get together in edition time > Thanks for this. The "stupendous aha <http://leoeditor.com/FAQ.html#what-is-the-stupendous-aha-and-why-does-it-matter>" is a natural way to organize virtually any sub-project within Leo. As I re-read the FAQ entry, I see that it probably should mention @button as an alternative to @test. @button creates a new command, so it's easy to rerun the command/test with Ctrl-P, repeat-complex command. > - Metadata associated with nodes can facilitate multiple views of the > same tree document. This is something I believe is in earlier stages of use > for Jupyter: e.g. offering multiple views of the same document using cell > annotations (e.g. cells as slides https://github.com/damianavila/RISE) or > filtering information > Jupyter uses a dropdown to show various views of data. This is a simple, effective, design. It's not perfect--Leo's VR pane is an alternative. Terry's new editor pane may allow something similar to the Jupyter dropdown. - Broader experience injecting different data-formats into the document > model (ReText, code, ...) than jupyter (with rare cases of use outside its > json format, like https://github.com/rossant/ipymd) > > On the other side, while I certainly like python and use it for many > purposes, it has been a while since I gave up to the idea that python > interfaces would be more solid than web UIs (javascript,...) And I think > leo deep roots on python can be a factor slowing down the adoption of some > of these technologies for the front-end. > Leo certainly would benefit from being a better platform for javascript and it's various semi-standard packages. > For literate programming interfaces there are things that modern > javascript and web technologies do very well: > * Moving to cooperative environments is relatively easier since you can > reuse much on the code in your desktop based application (e.g. > https://github.com/nteract/nteract) to deploy a multiuser server > application (https://github.com/nteract/commuter, https://cocalc.com/). > * Html rendering technologies really play well with advanced > visualization for all sort of multimedia information, from maps ( > https://github.com/OpenGeoscience/geonotebook) to scientific data plots ( > https://plot.ly/python/getting-started/) > * Web technologies favored frameworks with clear separation of Model-View > to facilitate content production (CSS, etc). This, although being > incorporated to desktop technologies like QML, can facilitate offering > multiple perspectives of the same document as mentioned before (mindmap, > slides, kanban board, etc e.g https://jaredforsyth.com/treed/) > * Having its roots in the web, javascript has very interesting > capabilities for concurrency, asynchronous operation, etc. Its a good > playground for technologies like functional programming, reactive > interfaces, declarative interfaces, etc. And it keeps growing in > popularity, with many available libraries and potential contributors > This seems to be an emerging consensus. When Joe Orr says he's "all in" on the web, I took notice. Fortunately, it seems python+javascript have the potential to coexist and > complement each other well, with some examples like dash > https://medium.com/@plotlygraphs/introducing-dash-5ecf7191b503 > Thanks for all these links. I'll put them in the project page, and study them when I can. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
