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/4b2ed232-d9c3-317d-4802-951ccb3e6a94%40riseup.net.
