Wow, lots of interesting mails here. I need some time to digest.
But it strikes me that the conversation involves the comparison of
graph or textual languages
without the necessary attention to the finer details. As Tom rightly
pointed out early in the thread,
the ixi lang is very graphical, and I guess some dataflow languages
can become pretty textual.
And now Julian says this:
> To my experience, it depends on where you come from how easy a
> system seems. For many people who have never soldered, patched etc.
> pd/max is far more difficult to understand conceptually than a text
> based system. If you come from literature, the magic of code is
> maybe more attractive than if you come from sound engineering or
> live electronics.
which is very interesting, but I wonder from where this knowledge is
derived? And what text based system
are you talking about? C or Impromptu? (Personally I find the former
much easier to understand
but that's just because I haven't had time to delve into Impromptu/
Fluxus/Sceme yet).
How about actually testing this systematically with some kind of
survey? Could we for example
each upload a video of a performance in our beloved live coding system
and then design some
kind of a survey where certain questions are asked with regards to
people's understanding of code?
(laypeople and coders alike)
The survey monkey survey Alex did the other day seemed easy to set up.
And it would be a nice toplappy open source science project to do.
Just an idea.
thor
>
> Apart from this, my impression is that the heart of live coding
> (just as eventually art and science) is to work against majoritarian
> intuition to establish unconditioned thought. This may take any
> shape whatsoever, and of course needs to depart from intuition. In
> other words, ergonomics makes sense if you know everything about the
> body, however it is a hindrance if you don't, because it does not
> yet exist.
>
> So a question perhaps: Is the attempt to make the audience
> understand as much as possible helpful for one's own understanding?
> I think yes, but it might be something different than sound that is
> understood.
>
>
>> Hi Group,
>>
>> I think there are some clues a step behind what we visually see.
>> The visual model is just information we actually interpret, but at
>> the same time is, as someone said already in this discussion,
>> practically irrelevant to the functional structure of algorithms in
>> PD/MAX type systems once they're made and executed.
>>
>> All that "mess" we see in a patch, which i would call "guts", is
>> some kind of higher level order that the computer doesn't need to
>> interpret but is useful for the experience of the developer. What
>> we are understanding is that the visual system of a human being is
>> far more complex and, maybe, impossible to model in a computer
>> system as we know them. That complexity in perception could be used
>> in the construction of a graphical programming language,
>> independent from which that could be. At last, we could be talking
>> about "auditory programming language" and the debate would be
>> somehow equivalent in its approach.
>>
>> greets,
>>
>> Diego
>>
>> 2009/10/5 Jeff Rose <<mailto:jeff_at_rosejn.net>jeff_at_rosejn.net>
>>
>> I see where you are coming from, and when I first used PD after
>> being a programmer for years I found it to be just a clunky
>> scripting language. For someone who is new to programming though,
>> I think this is far from the case. (I don't claim to be an expert,
>> but this is my current thinking after having taught a couple
>> semesters of undgraduate programing and having tutored my brother
>> in Max.)
>>
>> I think it has to do with your mental model while coding, more than
>> some technical difference in the languages. To someone who has
>> programming experience their is a large abstract model that comes
>> into "view" while you are working on a project. You balance all
>> sorts of things in your mind, from top level architectural
>> analogies to concrete syntactic constructs at your current line of
>> code. In an audio system you build up a picture of the signal and
>> control flows in your mind, and then modify and manipulate these
>> mental flows by writing functions.
>>
>> To a new programmer there is virtually a blank slate when first
>> coding though, and without having a toolbox of typical components
>> in mind or memories of past projects, I think it is very difficult
>> for beginners to keep an accurate mental model in mind. Having a
>> patch on screen, where you can constantly check things, look at
>> signals flow, watch buttons and number boxes update, etc., it all
>> helps very, very much to inform this nascent mental model. My
>> brother would create max patches where debug lines were connected
>> to almost everything possible because he liked to have a "live"
>> feel for what was happening in the patch. Even with modern IDEs
>> this is quite tedious to setup, let alone in emacs or vim (where I
>> feel at home). It also allows for run-time experimentation in a way
>> that even using a REPL doesn't duplicate. (Because you can easily
>> watch the effects of your changes on the rest of the patch, rather
>> than implicitly "watching" them in your mental model and then just
>> checking a variable or two to verify your intuitions.)
>>
>> So yeah sure, they are Turing complete and you still type function
>> names and arguments, but I think the real reason visual programming
>> is nice for people with no programming experience is because it
>> dramatically helps clarify and remind them of the working model of
>> their program.
>>
>> Interestingly, I think that this same benefit in the beginning
>> stages becomes the primary drawback at later stages. While in
>> "real" programming languages you have good tools for creating
>> abstractions so that you can think at higher and higher levels, I
>> think in Max you are kind of stuck at a sort of medium level of
>> abstraction no matter what. Big patches with many interconnected
>> components are far messier than the equivalent program would be,
>> and once you get to that point I think you already have to be
>> operating on a decent mental model anyways. (Which is I think why
>> many people who get proficient in Max want to move on to
>> programming in javascript, C, Clojure :-)
>>
>> That's my 2 cents anyway.
>>
>> -Jeff
>>
>>
>> alex wrote:
>>
>> 2009/10/5 Dave Griffiths <<mailto:dave_at_pawfal.org>dave_at_pawfal.org>:
>>
>> The difference between text and graphical programming seems fairly
>> arbitrary to me
>>
>>
>> I make this point every time this discussion comes up but it seems
>> no-one either agrees or disagrees with me. Maybe I'm not making any
>> sense. I'll try again.
>>
>> Pd and max are not graphical programming languages. They are
>> textual.
>> They are no more visual than C. You make an object and it does
>> nothing until you give it a name. Then you connect it to other
>> objects also with names. You move the boxes around the screen and
>> the
>> meaning doesn't change (except with weird edge cases in Max, but
>> that's a side issue).
>>
>> Maybe if I make an outrageous statement someone will disagree with
>> me;
>> when artists who say they find pd or max more intuitive than textual
>> languages because they are more visual and therefore more in tune
>> with
>> their visual thinking are plain wrong. They don't understand how
>> they
>> think, and don't know what they're doing, just like everyone else.
>> They are using a symbolic language to make art and shouldn't be
>> afraid
>> to admit it.
>>
>> There are language differences between PD and supercollider but
>> spatial and non-spatial is not one of them. Both allow symbolic
>> abstractions, loops and conditionals, and both require abstract
>> thought to make or understand a patch.
>>
>> <http://yaxu.org/textual-patching/>http://yaxu.org/textual-patching/
>>
>> I think what makes live coding is some system where a human
>> composes a
>> string of symbols from an alphabet, while a process interprets the
>> string according to some Turing complete language rules, so that the
>> interpreter follows changes to the code.
>>
>> You might have a language that isn't Turing complete, but still
>> allows
>> interesting abstractions, and call that live coding. I'm not sure if
>> I'd agree or not, that would be an interesting route to follow but
>> for
>> now I think the turing-completeness is important.
>>
>> alex
>>
>>
>>
>>
>> --
>> <http://labormedia.cl/algoritmia>http://labormedia.cl/algoritmia
>
>
> --
>
>
>
>
>
> .
Received on Mon Oct 05 2009 - 23:14:56 BST