--- On Thu, 9/23/10, IOhannes m zmoelnig <[email protected]> wrote:
> From: IOhannes m zmoelnig <[email protected]> > Subject: Re: [PD] jMax Phoenix > To: [email protected] > Date: Thursday, September 23, 2010, 9:20 AM > On 2010-09-22 20:04, Jonathan Wilkes > wrote: > > > > Yes, Max/MSP's [if] object has a more readable > syntax. Yet even > > i don't know max's [if], but i guess you could basically > implement this > with an abstraction. > > > with the two nested "ifs" I find it easier to read > than your > > implementation because I don't have to look up to the > inlet to > > remind myself which list elements correspond to which > variable. > > > > yes, but i believe this is because you are very used to > C-like > languages, so you assume that expr's if looks like: "if > <condition>, > <then>, <else>". > you have been trained on that, probably since high school > (and > eventually used it before) [*]. if you had been fed on > perl, you might > find other things more easily to read. > > > > I could put comments closer to each object chain, but > then that's > > even more objects. > > so? > > we all know that source-lines-of-code has nothing to do > with raedability > nor complexity. > more objects doesn't mean that the code is better OR worse > to read. > > (though of course it might be preferrable that the code > makes it clear > what is going on without having to resort to comments). > > >> and as a matter of fact, i don't think the > >> pd-implementation of the > >> algorithm is so bad. > > > > Yes, IMO the way you implemented it is nice because > there are > > very few wires crossing over objects. > > i think the main problems come from people trying to > implement C-like > control flow in a dataflow language like Pd. > even my implementation was only trying to reproduce the > algorithm you > wrote down, rather than trying to figure a Pd-way to > implement pong. > > you can make _very_ elegant super-readable control flow > with the use of > [route] and friends. > > > > > > I'd also mention I find it more difficult to patch > your > > implementation because there are 25 objects (not > including the > > number boxes), 16 of which correspond to the args of > [expr] in > > my implementation. That's 16 objects for which I > have to change > > modes between the mouse (for connections) and the > keyboard (for > > text). > > > if you find it difficult to patch 25 objects, then you > should get > yourself accustomed to keyboard short-cuts. > if you need go to the menu->put->object for each of > the 25 objects, then > i understand your concerns. with Ctrl-1 i don't see the > problem with > patching 25 or 3 objects. I use keyboard shortcuts but they don't help the problem of lining up objects with the mouse or with <shift-arrow>, and of making connections between objects which requires a click in a very specific place. Actually I find making 24 connections, one-at-a-time with the mouse to be the most tedious part of the whole ordeal. If I could just imagine the wires into existence then I might not use [expr] as much as I do. > > > > > > With [expr] I find it conceptually easier (and more > ergonomic) to > > set up my [v] objects, my [sel], and my [outlet], then > code the > > entire algorithm inside one box. > > i hardly ever use [value]. > i think it doesn't integrate so well into the patcher > paradigm, thus > making you want to program C-like rather than Pd-like. That's only true when using it in conjunction with [expr]. At least the other times I've used it have been basically a shortcut for: [s] | [f] > > that's not to say that i never use [value], it surely has > its merits. > > > > > Btw- you can get rid of 3 overlapping wires if you put > [value py] > > closest to [unpack 0 0 0] and cascade them that way. > > btw, i'm not very interested in getting rid of all > overlapping wires. > spaghetti code is probably something that is unreadable, > but the odd > overlapping wire is something my brain has adapted to > decyphering very well. > > fgmasdr > IOhannes > > > > > [*] note that i went to highschool in austria around 1990; > things might > have changed substantially since then. > > > -----Inline Attachment Follows----- > > _______________________________________________ > [email protected] > mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
