There is one area in Leo that is akin to live programming. That is running a Leo script that is in a subtree but is not a file. You can make a change and hit CNTL-b to rerun it. Behind the scenes the script gets turned into a file and the file gets run, but the user doesn't need to know that. I've got an app I'm working on right now that runs in a tab in the Log frame. I was able to devise a script the re-creates that tab and loads the app into it. It was a bit tricky to make work because it has to reload my app (to import it again with its changes). I made a button for that script, so I can make a code change, hit the button, and I'm ready to go in the tab with the changed code.
This is essentially live programming - as far as my personal perceptions are concerned - but it's a very simple, nearly self-contained thing. It doesn't change any of Leo's data structures, although it does get data from the outline's tree (well, it can change the current c.p position). I don't know how one could treat other parts of Leo this way, but I'm enjoying this bit of live programming. On Thursday, March 3, 2022 at 12:42:10 PM UTC-5 [email protected] wrote: > Hi, > On 3/03/22 8:52, Edward K. Ream wrote: > > In this Engineering Notebook post I'll explore changing Leo while Leo is > running. > > Imo, changing Leo "on the fly" is impossible, but thinking about what > would be necessary might suggest potential improvements to Leo > > *Background* > > Live coding is supposedly a killer feature of smalltalk. I have my doubts, > discussed below. > > > It is a killer feature. Most of the time when I see doubts about a not > well known/understood technology or alternative, it is mostly formulated > from the direct experience with the technology against what we're are > comparing it, in contrast to what we have heard about the alternative. I > not saying that this is your case, but it has happen to me, particularly in > programmers circles, when they are comparing lets say Pharo against more > popular computer languages/environments or Fossil against Git. Another > point is that the alternative is not similar enough to the > > *Barriers to changing running apps* > > All apps, regardless of language, are *inherently inflexible*: > > By some fundamental comparison, all apps can share some inherently > feature, being all Turing machines or equivalent in (virtual) machine code. > The issue for me, is the metaphors and experiences they provide when apps > are presented to us. That's why direct experience with alternatives, > particularly when they different to what we're used to is important. > > > 1. The architecture can't change. In particular, APIs are contracts that > can't easily be broken. Refactoring implies restarting the app. > > 2. Objects (instances of classes) contain data that must be retained. In > general, changing any module might change the data that the module computes. > > Live coding apps (in the arts) give the *illusion* of flexibility: > > 1. The app's architecture and primitives remain fixed (and inaccessible to > the artist). > 2. The artist's code is *rerun completely *whenever the code changes. > > I like the definition of architecture as the stuff that is difficult to > change [1][2] and in that sense the important thing would be how an app > bring us affordances to traverse/understand architecture (and maybe to > change it). Also language primitives are not fixed in Smalltalk based > environments. If you want, you could change the way booleans work on the > fly (and assume the consequences). > > [1] "Good Enogh" Architecture: https://youtu.be/PzEox3szeRc > [2] Architecture: The Stuff That's Hard to Change > https://youtu.be/3LtQWxhqjqI > > Coming back to different metaphors and experiences, instead of some > fundamental metric of equivalence (like rerunning on changes), the > distinctive factor would be the kind of understanding and conversations > that a live coding environment is enabling between the user/dev and the > artifact itself and how this have consequences in the creations/tasks at > hand. To have a glimpse of it, there is the, now classic, video "Inventing > on principle"[3] and for a more developer/coding oriented one, there is > "Moldable development"[4]. In both cases, because programming is not mainly > dealing with text and blindly manipulating symbols, and instead being > engage in a "artifact conversation" where different representations are > provided to easy such conversations and we can see the consequences of our > code in a more direct way over the artifacts. > > [3] https://vimeo.com/38272912 > [4] https://www.youtube.com/watch?v=Pot9GnHFOVU > > In my case, the conversation I had with textual artifacts, was easy by the > Leo affordances, when I was able to split and recombine the text at hand > (prose or code), according to my understanding of it. Pharo, Lepiter and > other live coding environments provide me with the possibility to run small > snippets of code and extend the representation of the system I'm dealing > with on the fly to increase my understading. I want. Grafoscopio is my > attempt to combine both experiences: live coding and outlining in a single > tool and to see the consequences of such tools in agency of grassroots > communities, starting at our local hackerspace (HackBo). > > * Summary * > > Live coding in the arts gives the illusion of dynamism. > > It's not possible to change the architecture of an app on the fly, > regardless of language. > > Reducing the static data in some of Leo's classes might simplify Leo. Or > not. I'll discuss this topic in another post. > > > My summary would be in the lines of the importance of which innevitable > illusions/metaphors we bring while building digital tools (as we're are not > dealing with changes in current in microprocessors) and the > affordances/capabilities they bring to our comunities (for example of > users). > > Cheers, > > Offray > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/b95b28bd-3615-4942-a834-392c085e8834n%40googlegroups.com.
