Re: [livecode] live 2013

From: Ross Bencina <rossb-lists_at_audiomulch.com>
Date: Fri, 18 Jan 2013 09:13:04 +1100

On 18/01/2013 8:54 AM, David Barbour wrote:
> there are many social and HCI aspects to PL design that are not
> widely acknowledged by the PL communities.

I think this is a widespread issue in software engineering. It reminds
me of a discussion with an software engineering professor who described
my concerns for usability of software systems as "non-functional
requirements."

There is a book called "Social Thinking - Software Practice" that I
found very helpful. ("Rationalizing Culture" is also a good one for the
Computer Music people.)


> 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.

I mostly follow your reasoning, but can you clarify what your criteria
for "better" are here please David? Do you have a set of requirements
for Live Programming that you're operating with?


> 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'm not sure that I understand why you say it's hidden. When I work in
C++ with the Visual Studio debugger I have full access to all program
state including process counters, queued messages etc etc. Effectively
the whole running program is a database that can be queried. And there's
edit-and-continue.

Is the main point that Live Programming expects to be able to query and
modify the program state *while it is running* ? hence has some
atomicity and consistency requirements on program state that you don't
have to worry about with stop-the-world debugging?

Ross.
Received on Thu Jan 17 2013 - 22:13:45 GMT

This archive was generated by hypermail 2.4.0 : Sun Aug 20 2023 - 16:02:23 BST