Hi, Comments inlined below.
On 10/8/18 4:58 AM, Edward K. Ream wrote: > When I finished swimming yesterday, the thought appeared that *Leo > isn't nearly good enough*. This was a /constructive/ thought, as I'll > explain here. These questions came to mind: > > - Why must we be continually reloading Leo? > - Why must we reload settings every time Leo starts? > - Why must code be this messy? > - Why can't we put unit tests near the code being tested? > - Why can't we use Rust to speed up Leo? > - Why can't we use javascript, or prolog within Leo? > - Why can't we catch errors sooner, with less harmful effects? > - Why is auto-completion so hard? > - Why can't we change Leo's appearance on the fly? > > The dream is to see changes safely and immediately, without reloading > Leo. Vitalije, Offray, Reinhard, Terry, among others have voiced > similar thoughts. These dreams are worth working on. > > Vitalije has complained about the slowness and complexity Leo's > settings. These complaints are perfectly valid in the context of > having big dreams. Loading Leo without having to reload > leoSettings.leo, myLeoSettings.leo and a theme.leo file is a > reasonable goal. > > Offray has compared the Smalltalk/Pharo world with the Python world, > and argued convincingly that Python can't emulate everything that > Pharo can do. > [...] > > I am not aware of any IDE that comes close to meeting these dreams. I > don't think Pharo counts as an IDE, but in any case I am not prepared > to rewrite Leo in another language. I don't have the time or energy > to do that, nor do I think adding Leo support to another IDE makes sense. > Pharo counts as an IDE, for sure, but is also something else. They talk about it as an IDE and OS rolled into one (an old and powerful idea from the times of the Dynabook[1][2] and other Big Dreams, lost in the early popularizing times of computing with the Unix paradigm). [1] https://en.wikipedia.org/wiki/Dynabook [2] https://archive.is/20121204161734/http://thinkubator.ccsp.sfu.ca/Dynabook I think that converting Leo to other languages makes little sense from a practical point, but exploring Leo ideas in other environments makes a lot of sense (and viceversa). What Leo can learn from Clojure and Smalltalk minimalist and modular approach to code writing via pure functions and pure objects? What Leo can learn from live coding in Pharo and interactivity on Jupyter? What all those environments and languages can learn from Leo and its idea of outline as core organizing/deconstructing unit for text? What I would like to see is more decoupling between the different parts of Leo, and Leo offering "outlining" services to data and documents coming from different places (including Jupyter notebooks, the file system, internet, data bases and so on). This is difficult, because there is a tension between providing an integrated experience easy for beginners and decoupling Leo so it can offer its advantages to other communities and users. So my approach would be to select specific communities and enhance Leo for them, starting with the Leo community itself and the proposal for outlines exemplifying particular workflows for users. I will try to expand a little bit on this: * Maria is a writer. She will like to use Leo to write prose and organize her writings. So she creates a Leo outline and starts to write several places of her work: characters, plot and publishing. For each of those she creates a Leo node and puts more children nodes, showing all characters, the plot parts and subplots and the publishing artifacts: a book in PDF and EPUB formats. Maria uses Leo clones when she needs to showcase how different parts of her work are connected and combines light formats for describing what she is doing: YAML for characters and their attributes and Markdown for prose in plot and publishing. Because Leo support all this formats and also directives, buttons and scripts, Maria is able to create the publishing she wants and automatize the process to focus in what she cares about: good storytelling. She can share a .leo document template so other writers can benefit from her workflow. The more technical part of the template (directives, buttons and scripts) was created with the help of the Leo community, where Maria started to share their early templates without any automatic behavior. * Gonzalo is a developer. He needs to read and understand code wrote by others and to adapt some pieces for his own needs and create new scripts that can be used with other code to suits his needs... * Rosana is a data scientist. She needs to load data from several sources and experiment with it interactively by making queries and visualizations... Once we have the different user stories, we try to see how Leo in its actual form can help to this people or how need to be changed. The important part of the stories is to think that all different Leo users are creating outlines and hope to see a particular behavior to make their life easier. We could try to track the original outlines and how they were changed with the help of the community and also how some functionality was incorporated in Leo to make it more usable for them. For example live Markdown rendering could be enabled by writing something in the Leo command line or from a graphical preview, without going into complex @settings files. Maybe this means some kind of qt widget that is able to render HTML and can be embedded into Leo, maybe some kind of service that auto-updates the view, with all the changes in machinery behind. That would connect Big Dreams with day to day lifes and issues --it's what I (we?) try to do at the Grafoscopio community. Hopefully this will make Big Dreams a little bit more approachable, reveling the human part of them and the wide community that Leo can serve. Cheers, Offray > *Keeping the dreams alive* > > The dreams are valuable, whatever happens: > > 1. They point to places where Leo could be significantly improved, > even if it means an /increase/ in complexity behind the scenes. > However, it's possible to imagine that some of the dreams could even > reduce the complexity of Leo's code. > > 2. They stimulate thoughts that would otherwise not arise. I like > working on these kinds of challenges. Leo came about because I > couldn't understand literate programs. > > 3. They encourage us to explore the literature on similar topics. > As I said in another message of this thread, is really good to see this Big Dreams happening and all the gains and discussions derived from it. In that sense I think that this is fulfilling the purpose stated in this 3 points. > *An irony* > > I have often said that we Python programmers act as if we /did/ know > the types of all objects. But this mind set turns Python into > something akin to Java or C. Bye bye flexibility and dynamism. > Python's classes are more sclerotic than we might like, a point that > Vitalije has made. > > *Summary* > > Each of the questions above suggests new possibilities for Leo. They > challenge all aspects of Leo's design and code. I'll write separate > posts discussing some of these questions. > > I am not going to rewrite Leo in another language. I /am /willing to > make large, incremental, changes to Leo. > > Your comments, please. Feel free to summarize your previous comments. > Now is the time for dreaming. > > 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] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > Visit this group at https://groups.google.com/group/leo-editor. > For more options, visit https://groups.google.com/d/optout. -- 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.
