Re: [livecode] ixi lang

From: Correa Diego <sigma.octantis_at_gmail.com>
Date: Mon, 5 Oct 2009 10:46:55 -0400

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 <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 <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/
>>
>> 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
Received on Mon Oct 05 2009 - 14:47:49 BST

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