I think it's also about building on Jupyter concepts as reproducible literate programming platform, not just cloning its current functionality
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) Things that "leopyter" could do better in my opinion would come from better underlying data structures: - Hierarchical document structure would result in more organized notebooks (example https://app.notablemind.org/tutorial/) - 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 - 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 - 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. 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/articles/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 - 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 - 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. 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 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 Just my 2 cents On Friday, October 27, 2017 at 10:48:13 AM UTC-4, Edward K. Ream wrote: > > > > On Thu, Oct 26, 2017 at 8:51 AM, Terry Brown <terry...@gmail.com > <javascript:>> wrote: > >> >> > Does this vision match yours? Here are some initial thoughts. >> >> My thoughts, which include a lot of groundless assumptions about how >> Jupyter works, would be that we have a new node type: >> > [big snip] > > > Thanks for all these thoughts. I have copied them into #561 > <https://github.com/leo-editor/leo-editor/issues/561> for reference. > I also added some short, anodyne comments ;-) > > I think it was a mistake to create a separate thread for #561 here on > leo-editor. Let's continue the discussion either on #561 itself or in the > jupyter > project page <https://github.com/leo-editor/leo-editor/projects/1>. > > > 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
