On Sat, Jan 12, 2013 at 4:27 PM, alex <alex_at_lurk.org> wrote:
>
> > My interest in live programming has never been about performance (which
> > seems the primary interest of this list). Rather, to me it is about
> > understanding PL as a form of HCI. There is undeniably a gap in practice
> > between PL and HCI, but I think it is not essential. It's more like a
> > canyon... a consequence of where we chose to settle.
>
> The Psychology of Programming is a pleasant valley between them, and
> generally a good place to shelter from the aggression on either side.
> :)
>
If you're just looking for shelter, perhaps. But if I'm searching for
progress, I won't find links to PPIG. :)
>
> > There are regions in the design space where the distinction between PL
> and
> > HCI is weak, I.e. where intuitions, patterns, principles, extension and
> > composition learned in one are directly applicable to the other.
>
> Yes I think there is huge value in breaking down this distinction,
> especially when we look at how people work with command lines,
> spreadsheets, web search..
>
Spreadsheets are an excellent example of a programming interface that users
easily grasp, yet are insufficient for real world programming. I'm hoping
my RDP model will create the new spreadsheet - better at abstraction,
composition, and side-effects. Command line interfaces are also a fine
example - especially when they result in non-textual artifacts (e.g.
charts, graphs, widgets, sounds, behaviors).
>
> > The ultimate audience for live programming should be everyone.
>
> I agree but there are two things being conflated:
>
> [programming] -> [music] -> [audience]
> [programming] -> [audience]
>
> In the second case the audience is supposed to understand and enjoy
> the code itself. This is often a design consideration of live
> programming languages, for example I seem to remember Ge Wang saying
> that this was a main reason why he made ChucK. The obvious counter is
> that you don't have to be able to play the guitar to enjoy listening
> to someone play one
>
To clarify, I think that the relationship between "live programming" and
"music" is one of community interest, not of any essential nature. Live
programming is just as useful for dungeon-mastering a live group in a
virtual world or interactive fiction, or maintaining and extending a 24/7
service (e.g. a sales website or MMORPG). Being from outside this
community, I'm very much not inclined to conflate live programming with
music. And even if you assume an audience is necessary, that could broadly
include such things as as users of a service, players in a game.
When I say live programming is for everyone, I don't mean that they should
'enjoy' it - just that they should participate in it. User-interfaces and
their elements should be modeled as live programs in a language, i.e. such
that every element can be inspected, extended, composed, abstracted,
reused, remixed. Even if most users don't program, just using their UIs
should subtly teach useful programming principles and intuitions, providing
easy literacy for when they change their minds (as will often be the case
for *young* users). I believe that requires creating a new paradigm, one
closely aligned to HCI.
What everyone in the audience will 'enjoy' are the network effects of such
a system: the user-generated content; the plethora of extensions and tweaks
coming from the hundreds or thousands of users who like (or don't mind)
programming.
> This also presupposes that the programmer themselves knows what
> they're doing -- for me the point of live programming is that you
> don't know what you're doing, otherwise it wouldn't be a live
> interaction. Live programming should be one long surprise.
>
Only a bad tool will make it difficult to achieve competence, and only a
fool will fail to understand his own limits. Live programming is
potentially the "ultimate" tool - one of great flexibility and application,
and growing more so as programmable elements and networks become more
ubiquitous. Live programming shouldn't be more 'surprising' than any other
live performance. There will always be enough external challenges (e.g.
matching moods and themes, reacting to audience and environment, breathing
life into our own short-lived inspirations and witticisms, collaborative
efforts) that we really don't need to handicap ourselves or our tools just
to keep it interesting.
I think, rather than saying "live programming should be one long surprise",
it might be better to say "live programming should always allow me to
stretch beyond my limits, improvise, learn, and find new limits". And
that's perfectly reasonable. After all, that's half of what distinguishes
*programming* (live or not) from simple consumption.
Warm Regards,
Dave
Received on Sun Jan 13 2013 - 02:16:17 GMT