Can anyone direct me to articles on constructing clear, modular, non-spaghetti patches in pd or other visual dataflow languages? Especially if the articles derive their recommendations from theoretical analysis (as with the investigations that led to structured programming in imperative languages), rather than just rules-of-thumb -- although the latter are useful also.
Or is some amount of spaghetti unavoidable in dataflow languages, perhaps because it is inherent in the situation being modeled, rather than being an artifact of the language?
Thanks.
I am not sure, if there are any scholarly articles about structured programming style guidelines for visual programming languages. I've seen only rules-of-thumb. hey, there is not even a "return" command (to a main program?). only inlets and outlets. I am not even sure about the analogy of function, class, object when comparing C or C++ to a graphical dataflow programming language (which pd is?). actually, the data is not flowing at all, it is the objects' function code that pilgers to the sanctuaries of stored data and accomplishes its task there... marius.
Dudley Brooks wrote:
Can anyone direct me to articles on constructing clear, modular, non-spaghetti patches in pd or other visual dataflow languages? Especially if the articles derive their recommendations from theoretical analysis (as with the investigations that led to structured programming in imperative languages), rather than just rules-of-thumb -- although the latter are useful also.
Or is some amount of spaghetti unavoidable in dataflow languages, perhaps because it is inherent in the situation being modeled, rather than being an artifact of the language?
Thanks.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I think Marius is right saying there's little formal advice on visual dataflow structuring. Someone did a "styleguide" with do's and dont's, but I cant find the link....anyone?
You could apply most of JSD and general software engineering principles to visual dataflow though.
Cohesion: Keep things together (spacially, per file/abstraction) that have related function.
Coupling: Don't let too many unrelated things hang off the same value or method (or outlet in Pd)
Factoring: Elmininate redundancies
Abstraction: If you're doing for a third time it's probably time to abstract it.
Reuse: see abstraction :)
Flow: Don't overuse [send][receive], the wires are like the ordering of code lines and a Pd program is read downwards (and maybe right to left?)
Comments: Use them, write your code so you can read it in two weeks time.
On Fri, 11 Jan 2008 21:00:30 -0500 marius schebella marius.schebella@gmail.com wrote:
I am not sure, if there are any scholarly articles about structured programming style guidelines for visual programming languages. I've seen only rules-of-thumb. hey, there is not even a "return" command (to a main program?). only inlets and outlets. I am not even sure about the analogy of function, class, object when comparing C or C++ to a graphical dataflow programming language (which pd is?). actually, the data is not flowing at all, it is the objects' function code that pilgers to the sanctuaries of stored data and accomplishes its task there... marius.
Dudley Brooks wrote:
Can anyone direct me to articles on constructing clear, modular, non-spaghetti patches in pd or other visual dataflow languages? Especially if the articles derive their recommendations from theoretical analysis (as with the investigations that led to structured programming in imperative languages), rather than just rules-of-thumb -- although the latter are useful also.
Or is some amount of spaghetti unavoidable in dataflow languages, perhaps because it is inherent in the situation being modeled, rather than being an artifact of the language?
Thanks.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
There is a great thread on Cycling 74s site concerning OO and dataflow
styles, dos and donts.
http://www.cycling74.com/forums/index.php?t=msg&th=25272&start=0&...
On Jan 11, 2008, at 9:37 PM, Andy Farnell wrote:
I think Marius is right saying there's little formal advice on visual dataflow structuring. Someone did a "styleguide" with do's and dont's, but I cant find the link....anyone?
You could apply most of JSD and general software engineering principles to visual dataflow though.
Cohesion: Keep things together (spacially, per file/abstraction)
that have related function.Coupling: Don't let too many unrelated things hang off the same value or method (or outlet in Pd)
Factoring: Elmininate redundancies
Abstraction: If you're doing for a third time it's probably time to abstract it.
Reuse: see abstraction :)
Flow: Don't overuse [send][receive], the wires are like the ordering of code lines and a Pd program is read downwards (and maybe right to
left?)Comments: Use them, write your code so you can read it in two weeks
time.On Fri, 11 Jan 2008 21:00:30 -0500 marius schebella marius.schebella@gmail.com wrote:
I am not sure, if there are any scholarly articles about structured programming style guidelines for visual programming languages. I've seen only rules-of-thumb. hey, there is not even a "return" command (to a main program?). only inlets and outlets. I am not even sure about the analogy of function, class, object when comparing C or C++ to a graphical dataflow programming language (which pd is?). actually, the data is not flowing at all, it is the objects' function code that pilgers to the sanctuaries of stored data and
accomplishes its task there... marius.Dudley Brooks wrote:
Can anyone direct me to articles on constructing clear, modular, non-spaghetti patches in pd or other visual dataflow languages? Especially if the articles derive their recommendations from
theoretical analysis (as with the investigations that led to structured
programming in imperative languages), rather than just rules-of-thumb --
although the latter are useful also.Or is some amount of spaghetti unavoidable in dataflow languages, perhaps because it is inherent in the situation being modeled,
rather than being an artifact of the language?Thanks.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- Use the source
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Fri, 2008-01-11 at 11:29 -0800, Dudley Brooks wrote:
Can anyone direct me to articles on constructing clear, modular, non-spaghetti patches in pd or other visual dataflow languages? Especially if the articles derive their recommendations from theoretical analysis (as with the investigations that led to structured programming in imperative languages), rather than just rules-of-thumb -- although the latter are useful also.
You might find this document interesting if not helpful:
http://dspace.mit.edu/handle/1721.1/13474
Or is some amount of spaghetti unavoidable in dataflow languages, perhaps because it is inherent in the situation being modeled, rather than being an artifact of the language?
Personally, I find that there is an idiomatic way to use most languages, which is congruous with the way the language is designed. Of course, people may want to deliberately subvert this relationship, but I guess that's different from using something in an unidiomatic way and not being aware of the fact.
Although, I think Frank wrote these in a non-didactic spirit, I find Franks 'dogmas' very helpful for clear and idiomatic Pd patching:
http://lists.puredata.info/pipermail/pd-list/2007-04/049447.html
I have also found Frank's 'footils' collection of abstractions to be an excellent source of idioms and examples of how to make clear and coherent patches.
I must stress that I'm not suggesting that this is the 'correct' way to patch, I just personally find it to be clear, elegant and spaghetti avoiding!
best,
Jamie
This stuff would be excellent to have gathered on a wiki page so
people don't have to hunt thru archives, etc.
.hc
On Jan 12, 2008, at 8:41 AM, Jamie Bullock wrote:
On Fri, 2008-01-11 at 11:29 -0800, Dudley Brooks wrote:
Can anyone direct me to articles on constructing clear, modular, non-spaghetti patches in pd or other visual dataflow languages? Especially if the articles derive their recommendations from
theoretical analysis (as with the investigations that led to structured
programming in imperative languages), rather than just rules-of-thumb -- although the latter are useful also.You might find this document interesting if not helpful:
http://dspace.mit.edu/handle/1721.1/13474
Or is some amount of spaghetti unavoidable in dataflow languages, perhaps because it is inherent in the situation being modeled, rather than being an artifact of the language?
Personally, I find that there is an idiomatic way to use most
languages, which is congruous with the way the language is designed. Of course, people may want to deliberately subvert this relationship, but I guess that's different from using something in an unidiomatic way and not being aware of the fact.Although, I think Frank wrote these in a non-didactic spirit, I find Franks 'dogmas' very helpful for clear and idiomatic Pd patching:
http://lists.puredata.info/pipermail/pd-list/2007-04/049447.html
I have also found Frank's 'footils' collection of abstractions to
be an excellent source of idioms and examples of how to make clear and coherent patches.I must stress that I'm not suggesting that this is the 'correct'
way to patch, I just personally find it to be clear, elegant and spaghetti avoiding!best,
Jamie
-- www.postlude.co.uk
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Mistrust authority - promote decentralization. - the hacker ethic
This all makes me think that we should write a Pd book that covers
things like good form. Perhaps we could make it a decentralized
collaborative effort with strange consensus decisionmaking to mirror
the Pd community :D
.hc
On Jan 12, 2008, at 8:41 AM, Jamie Bullock wrote:
On Fri, 2008-01-11 at 11:29 -0800, Dudley Brooks wrote:
Can anyone direct me to articles on constructing clear, modular, non-spaghetti patches in pd or other visual dataflow languages? Especially if the articles derive their recommendations from
theoretical analysis (as with the investigations that led to structured
programming in imperative languages), rather than just rules-of-thumb -- although the latter are useful also.You might find this document interesting if not helpful:
http://dspace.mit.edu/handle/1721.1/13474
Or is some amount of spaghetti unavoidable in dataflow languages, perhaps because it is inherent in the situation being modeled, rather than being an artifact of the language?
Personally, I find that there is an idiomatic way to use most
languages, which is congruous with the way the language is designed. Of course, people may want to deliberately subvert this relationship, but I guess that's different from using something in an unidiomatic way and not being aware of the fact.Although, I think Frank wrote these in a non-didactic spirit, I find Franks 'dogmas' very helpful for clear and idiomatic Pd patching:
http://lists.puredata.info/pipermail/pd-list/2007-04/049447.html
I have also found Frank's 'footils' collection of abstractions to
be an excellent source of idioms and examples of how to make clear and coherent patches.I must stress that I'm not suggesting that this is the 'correct'
way to patch, I just personally find it to be clear, elegant and spaghetti avoiding!best,
Jamie
-- www.postlude.co.uk
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Man has survived hitherto because he was too ignorant to know how to
realize his wishes. Now that he can realize them, he must either
change them, or perish. -William Carlos Williams
a book, or at least we should improve the tutorial situation. is there a google summer of documentation? collecting/creating/restructuring the tutorials section (wiki.blender.org is a good example) - I still would like to see this closely related to pdpedia. tutorials - forums - mailinglist (incl. archive) - pdpedia - gallery - other resources; there *must* be a better way to structure these. marius.
Hans-Christoph Steiner wrote:
This all makes me think that we should write a Pd book that covers
things like good form. Perhaps we could make it a decentralized
collaborative effort with strange consensus decisionmaking to mirror
the Pd community :D.hc
On Jan 12, 2008, at 8:41 AM, Jamie Bullock wrote:
On Fri, 2008-01-11 at 11:29 -0800, Dudley Brooks wrote:
Can anyone direct me to articles on constructing clear, modular, non-spaghetti patches in pd or other visual dataflow languages? Especially if the articles derive their recommendations from
theoretical analysis (as with the investigations that led to structured
programming in imperative languages), rather than just rules-of-thumb -- although the latter are useful also.You might find this document interesting if not helpful:
http://dspace.mit.edu/handle/1721.1/13474
Or is some amount of spaghetti unavoidable in dataflow languages, perhaps because it is inherent in the situation being modeled, rather than being an artifact of the language?
Personally, I find that there is an idiomatic way to use most
languages, which is congruous with the way the language is designed. Of course, people may want to deliberately subvert this relationship, but I guess that's different from using something in an unidiomatic way and not being aware of the fact.Although, I think Frank wrote these in a non-didactic spirit, I find Franks 'dogmas' very helpful for clear and idiomatic Pd patching:
http://lists.puredata.info/pipermail/pd-list/2007-04/049447.html
I have also found Frank's 'footils' collection of abstractions to
be an excellent source of idioms and examples of how to make clear and coherent patches.I must stress that I'm not suggesting that this is the 'correct'
way to patch, I just personally find it to be clear, elegant and spaghetti avoiding!best,
Jamie
-- www.postlude.co.uk
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Man has survived hitherto because he was too ignorant to know how to
realize his wishes. Now that he can realize them, he must either
change them, or perish. -William Carlos Williams
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Two books that helped me learn how to write clearly modularized programs were Starting Forth (1981) and, especially, Thinking Forth (1984) by Leo Brodie. Of course, these are for a particular language, and one which encourages -- you might even say requires -- modularization. But a lot of the tips are about how to *think* about the program you're creating, so they carry over into other languages. And they're especially good for showing what can be done even in low-level languages ... like Forth and Pd.
Hans-Christoph Steiner wrote:
This all makes me think that we should write a Pd book that covers things like good form. Perhaps we could make it a decentralized collaborative effort with strange consensus decisionmaking to mirror the Pd community :D
.hc
On Jan 12, 2008, at 8:41 AM, Jamie Bullock wrote:
On Fri, 2008-01-11 at 11:29 -0800, Dudley Brooks wrote:
Can anyone direct me to articles on constructing clear, modular, non-spaghetti patches in pd or other visual dataflow languages? Especially if the articles derive their recommendations from theoretical analysis (as with the investigations that led to structured programming in imperative languages), rather than just rules-of-thumb -- although the latter are useful also.
You might find this document interesting if not helpful:
http://dspace.mit.edu/handle/1721.1/13474
Or is some amount of spaghetti unavoidable in dataflow languages, perhaps because it is inherent in the situation being modeled, rather than being an artifact of the language?
Personally, I find that there is an idiomatic way to use most languages, which is congruous with the way the language is designed. Of course, people may want to deliberately subvert this relationship, but I guess that's different from using something in an unidiomatic way and not being aware of the fact.
Although, I think Frank wrote these in a non-didactic spirit, I find Franks 'dogmas' very helpful for clear and idiomatic Pd patching:
http://lists.puredata.info/pipermail/pd-list/2007-04/049447.html
I have also found Frank's 'footils' collection of abstractions to be an excellent source of idioms and examples of how to make clear and coherent patches.
I must stress that I'm not suggesting that this is the 'correct' way to patch, I just personally find it to be clear, elegant and spaghetti avoiding!
best,
Jamie
-- www.postlude.co.uk
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
Hans-Christoph Steiner wrote:
This all makes me think that we should write a Pd book that covers
things like good form. Perhaps we could make it a decentralized
collaborative effort with strange consensus decisionmaking to mirror
the Pd community :D
i guess that Pd might be out of existence when the book will be ready...
seriously, i do think that there are fundamentally (and not so fundamentally) different views on "good form" (as all the flaming on [t a] vs. [trigger anything] shows), and i don't think that we would come to a conclusion.
so i see 2 approaches to such project:
- a collection of several individiual "good style" articles; possibly
contradictory (e.g. in the way of the "beautiful code" book that primarily shows how differently "beauty" is perceived)
- a single (group of) person(s) that write(s) the book and can decide on
their definition of "good style"; since they do all the work, they have all the right to ignore (or whatever) other opinions
i personally would favour #1, but i think both approaches are legitimate
fgmadsr. IOhannes
-
Andy Farnell -
Dudley Brooks -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Jamie Bullock -
marius schebella -
vade