Hello, Abraham.
As you discerned, dealing with *state* is a challenge for live programming
systems.
There are a few cases you missed:
*5.* Record inputs in a deterministic manner; execute new code by
processing old inputs. This technique is often used when developing
interactive fictions (e.g. by the Inform 7 community). Doesn't scale well
to very long-lived systems, but works quite well in many use-cases.
*6.* As 5, but with snapshots, undo, or rewind. We only replay a subset of
inputs. This improves scalability, but also requires a consistent model for
working from a snapshot.
*7. *Model a program as a series of piped ops where the current output can
depend strictly on the last K inputs (or 'seconds of' input). K might vary
from one step to another. A change in code will affect future outputs, but
previous outputs are not affected. The volatile nature of the state ensures
the system eventually acts as though the new code was installed all along;
however, access to historical inputs provides greater "smoothness" to the
transitions: the immediate output might be turbulent, but after a few steps
downstream it's all smooth again.
*8. *Like 7, but using an exponential decay model instead of a windowed
history. Exponential decay can be modeled a number of ways, the most
traditional is simply to use a damping function like `x_at_t = 0.8*(x_at_(t-1))
+ 0.2*observation`, which means x is affected by its *entire* history...
but affected more by recent history than by distant history. We can also
model exponential decay with lists. [1][2] (which is a good basis for
snapshots, btw).
*9. *We can also model "semantically stateless" stability models, i.e.
based on metastability [3]. These can give us 'smoothness' in our outputs
while also tolerating massive changes. The cost is logical non-determinism.
This technique is a good fit for weighted logics and soft constraints, and
seems remarkably applicable to art development [4].
*10.* Time is the only state. The behavior of code at any given instant
depends either on a wall clock or some external 'clock' process that ticks
along. This works really well for certain applications (e.g. rotating
animations), but has the unfortunate consequence of lacking smooth
transitions across a code change.
Regarding your point *4*, that is well addressed by the time warp protocols
[5][6] and less directly by Sean McDirmid's work [7].
The approach I'm developing - Reactive Demand Programming (RDP) - uses a
mix of techniques: RDP keeps state external (method *3*) so it is easy to
separate from the application. Updated code will swap out at a precise
logical instant (method *2*), but keeping this instant 'precise'
potentially requires a little bit of backup and correction of state like a
time-warp system (method *4*). Fortunately, that analysis is trivial since
I'm using continuous signals (instead of fire-and-forget messages). Dynamic
programs work the same way as code update, so there is a nice bit of
formality and uniformity there.
External state is sometimes painful to work with (due to poor
encapsulation), so I support exclusive binding to external state in a
manner that will be stable across source changes [8]. That gives me the
benefits of local state, e.g. for singletons, while still supporting
orthogonal persistence and runtime updates. But though I can support ad-hoc
state models, I favor mechanisms that depend only on recent observations,
or that use exponential decay, or stateless stability - i.e. state models
that are at once useful for stable/smooth behavior but robust or resilient
to corruption.
Best,
David Barbour
[1]
http://awelonblue.wordpress.com/2013/01/24/exponential-decay-of-history-improved/
[2]
http://en.wikipedia.org/wiki/Backup_rotation_scheme#Tower_of_Hanoi
[3]
http://en.wikipedia.org/wiki/Metastability
[4]
http://awelonblue.wordpress.com/2012/09/07/stateless-stable-arts-for-game-development/
[5]
http://cell-devs.sce.carleton.ca/publications/2008/LW08/
[6]
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.134.6637
[7]
http://lambda-the-ultimate.org/node/4715
[8]
http://awelonblue.wordpress.com/2013/08/26/source-stable-uniqueness/
On Sat, Aug 3, 2013 at 4:32 AM, Abraham Coetzee <abraham_at_ml.sun.ac.za>wrote:
> Hi everyone.
> I'm a computer science masters student at Stellenbosch University, South
> Africa, and am investigating live programming as part of visual thinking in
> computer programming.
>
> I am curious about the different ways employed to propagate source code
> changes, in running as well as 'paused' programs (say at a breakpoint). It
> would be very interesting to know which live programming/coding systems use
> which approach, so that one can take a look at other, similar systems when
> developing one, or design systems which are unlike any before. I am
> interested not as much in 'transient'/ephemeral code, but more in
> 'permanent' code where the program is always linked to- and (the algorithm)
> reproducible by- the final source code. Perhaps one could also say, not
> transient code where the state/outcome produced that single time is the
> most important (often the case when using a REPL setup), but I am thinking
> more of permanent code where the final, created code is important (often
> the case when using an edit-compile-run-debug cycle). Though of course both
> transient and permanent programming have their place.
> For instance:
> *1*. When code is changed, the program might end and then simply
> re-execute from the start.
> *2*. A library, when changed, could just be reloaded so that the next
> time it is refered to, it produces different results. (Though I think this
> isn't quite 'permanent' as the program partly executed using older code and
> so the current state *might* depend on what the code use to be.)
> *3*. The programming language or system is designed so that state is an
> entity that can be worked with - e.g. saved and again loaded when the
> program is re-executed with new source code.
> *4*. Some sort of dependency analysis to figure out what consequent code
> is affected by a code change. Then either where in the source code to back
> up to and re-execute from, or how to transform the current program so that
> it is as if it executed with the new source code in the first place.
> - Any others? Those are all I can think of.
>
> I'd appreciate your input.
> Thank you,
> Abraham
>
Received on Tue Sep 03 2013 - 19:14:36 BST