On Thu, Jan 17, 2013 at 12:01 PM, alex <alex_at_lurk.org> wrote:
> On 17 January 2013 19:29, David Barbour <dmbarbour_at_gmail.com> wrote:
> > Live programming is at least as much a function of IDE, API, and program
> > architecture as the programming language itself.
>
> Yes, actually in broad discussions of programming HCI, I consider all
> those to be aspects of "programming language", along with the means of
> notation, including secondary notation (comments, syntax colour
> highlighting). This is in the same sense that prosody is important to
> spoken natural language.
>
It is wonderful to know other people feel that way. Even putting aside live
performance, there are many social and HCI aspects to PL design that are
not widely acknowledged by the PL communities.
>
> > It seems controlling use of local state is important if we both want rich
> > abstraction - i.e. where composite networks can be abstracted - and live
> > programming. (cf.
> > http://awelonblue.wordpress.com/2012/10/21/local-state-is-poison/)
>
> I enjoy live coding when the only state (apart from the running code)
> is time, and where a program uses it like a one-dimensional thread
> that it knits into multidimensional musical structures.
>
A useful feature for live programming is an ability to reason about a
program's behavior in terms of its code and environment - in particular,
while remaining ignorant of the *history* of that code and the *history* of
that environment (except insofar as the history is explicitly recorded in
the environment). A consequence is a nice stability property: that
restarting the system does not have any semantic impact on its behavior.
Even putting aside explicit mutable state, most "running code" has a lot of
implicit state: process counters for control flow; conditional expressions
that lead to closed loops; delayed messages that carry information from the
past to the future; accumulation of random value decisions or user inputs.
This implicit local state can cause similar difficulties as mutable
variables, perhaps is even worse because it's hidden from the programmer
during edits.
I think it would be better for most implicit local state from running code
to be externalized, i.e. into a database or tuple space. Though, it would
be fine if said state model was tightly integrated with the PL.
--
bringing s-words to a pen fight
Received on Thu Jan 17 2013 - 21:55:03 GMT