I agree with much of what both Andrew and Georg said.
When Andrew gave his permutation example, the first solution that came to
mind was a functional approach similar to what Georg proposed. But this
still speaks to the difficulty in generalizing these techniques as Andrew
mentioned; we have to adopt a particular methodology to solve the "problem"
(which shouldn't be a problem in the first place) within the constraints of
the visual feedback system.
For me an important question is: do the benefits of these techniques
outweigh the costs? The benefits have yet to be quantified in a meaningful
way (at least that I know of), but, judging by the survey results so far,
seem to be intrinsically attractive to this community. The costs include
both increased development time for coding environments and a requirement
for artist-programmers to work within provided constraints.
And of course there are the alternatives that Andrew mentioned to consider,
such as the graphical overlays added to Impromptu / Extempore or the live
variable view found in urMus.
Georg, I like the idea of a language with those design goals! Would be a
lot of fun to think about / work on.
On Fri, Jan 30, 2015 at 6:02 PM, Georg Essl <gessl_at_umich.edu> wrote:
> > [0,1,2,3].permutations;
>
> > When you mess around with the text, you
> are messing around with the semantics of the language (as the two examples
> above should highlight).
>
> Certainly code text changing could be somewhat disruptive for a programmer
> so there may be some sort of cognitive issue with text substitution
> strategies.
>
> Still a cool idea and I can see specific settings where it could have good
> properties. Charlie uses Rand in his video, and that one actually seems to
> work. Here are other examples that came to mind reading Andrew's post:
>
> Say something like permutations is used temporally. And it is an operator
> that rather than explode all possible permutations, iterates through all
> possible permutations.
>
> For example if at T1 the code text reads [0,1,2,3].permutations; and at T2
> it reads [0,3,1,2].permutations; etc . This would actually add clarity to
> the text (by making the "current" state explicit) while remaining
> syntactically correct.
>
> If the program is paused and resumed this would actually have the neat
> advantage of visibly retaining the correct "seeding position" of the
> "active" permutation. You'd need to reset that seed when the program is run
> from scratch, but that's not a huge issue.
>
> Reverse in a temporal loop also seems to have these properties. At T1 the
> code reads [c,d,e,f#,g].reverse; at T2 it reads [g,f#,e,d,c].reverse; at T3
> it reads [c,d,e,f#,g].reverse; etc. I.e. it could get the identical
> advantage of making state explicit and robust through pause/resume.
>
> Of course this does assume a specific temporal realization of
> .reverse/.permutation/.rand, but seems quite doable.
>
> But it is a specific set of in-place substitutable things (perhaps with
> some additional invariants attached) where something like this can work out
> and have some added benefit.
>
> In the big picture, I think the question how we can relate run-time state
> back into the code representation is really important and interesting.
> Could be a fun thing to try to actually sketch out a language with the
> property that all run-time states/consequences induced by code must have a
> visualizable code-side representation.
> --
>
> Read the whole topic here: livecode:
> http://lurk.org/r/topic/SB05bOx0znBLOby5zA6US
>
> To leave livecode, email livecode_at_group.lurk.org with the following email
> subject: unsubscribe
>
--
Read the whole topic here: livecode:
http://lurk.org/r/topic/6PiR5OtXV0TZvbdGlTUyKh
To leave livecode, email livecode_at_group.lurk.org with the following email subject: unsubscribe
Received on Sat Jan 31 2015 - 21:10:12 GMT