[PD] "Structured" dataflow?

vade doktorp at mac.com
Sat Jan 12 04:57:37 CET 2008


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&rid=0&S=6bc17f0fd0e897fcb6a32801e8ab41ed


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 at 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 at iem.at mailing list
>>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>>>
>>
>>
>> _______________________________________________
>> PD-list at iem.at mailing list
>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>
>
> -- 
> Use the source
>
> _______________________________________________
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list





More information about the Pd-list mailing list