On 18 January 2013 01:42, David Barbour <dmbarbour_at_gmail.com> wrote:
> On Thu, Jan 17, 2013 at 2:36 PM, alex <alex_at_lurk.org> wrote:
>> > except insofar as the history is explicitly recorded in
>> > the environment
>> That's a big "except insofar" though.
> Indeed. It's also the essential nature of state. We can't observe the past,
> only the present. Programmable state comes from maintaining a record of
> observations, such that the record is available in the present.
I was trying to point at the wider environment outside the computer.
In live coding, a single state of code is not enough to represent the
program, the edits to the program are part of it. Those edits may be
recorded and later manipulated by the user or perhaps even the running
code.
> To accommodate disruption, it's best if the computation of
> passive behavior is trivial (no expensive accumulators).
Yes, like I say I like to just have time as the only accumulator.
> We can design live programming systems that accommodate CSCW and security
> properties, where mutually distrustful developers update different parts of
> the system. If someone edits the same code you're about to edit, that's a
> bit more difficult to handle, though a language that provides nice
> composition properties (e.g. commutativity, associativity, idempotence,
> stability, resource control) can help address the issue.
The reactable is a good example of a multiuser programming language
interface, Euclidean syntax is an interesting aspect of its multiuser
usability (multi-usability?).
> The two conditions are orthogonal, unless you assume that every program has
> ambient authority to edit its own source code. (Self-modifying code has
> plenty of its own issues.)
I used a live programming editor for quite a few years where the code
could edit itself, although I rarely triggered re-interpretations from
the code. It was useful for keeping state in the sourcecode, a kind of
restart-recovery. Also generally useful for giving feedback about what
the program was doing in comments. I miss it a bit, it made the source
code more of a user interface, like it is in PD/Max. Being in Perl
though, making code that reasoned about itself was out of the
question.. :)
http://www.perl.com/pub/2004/08/31/livecode.html
>> You can contain purity inside monads, but
>> introducing liveness makes it all impure again, doesn't it?
> It depends on whether the live edit can be observed or influenced by the
> edited program. :)
A good point..
>> except the fact that everything halts eventually.
> Why so sure?
Supernovae!
alex
Received on Fri Jan 18 2013 - 09:48:55 GMT