Theory vs. Practice

[Morgan Sutherland]

Greetings Folks,

I was happy to come across this group as a long-time Max/MSP user who is frustrated that similar tools do not exist for purposes other than multimedia. Moreover, I have been quite frustrated with certain aspects of Max and have been toying with the idea of creating something new, though this would be a massive undertaking and others have done the same (see Lubyk, vvvv, Quartz, even DrawFBP, which I've just learned about, and countless smaller projects).

I'm writing here to say that I've been going through some of the posts to this list and I'm struck by what appears to me as a sort of – pardon me for putting it this way – naiveté about how "FBP" (or dataflow programming as we call it) works in practice.

For instance, I've just finished the thread about creating a new language for FBP, which evolved into a discussion of notations for graphs. My first thought after having studied a few of the proposed notations, and also having taken a fairly close look at NoFlo, is that these notations are really untenable for any non-trivial task where each component is appropriately decomposed (following the "do one thing well" philosophy). I'm not even convinced that there can be such a notation, but allow me to mention a few problems:

1. I would estimate that a text-based graph language would be at least twice as slow as editing a diagram. I love text editing and I'm often frustrated by how much more productive I feel in Vim vs. most GUI apps, but this is because most GUI apps are not designed to accomodate expert use. An appropriately designed graph editor – ideally configurable like Vim – would be extremely fast (this doesn't exist yet, btw, and would be a great project). Nevertheless, the current graph editor for Max, which I believe to be the most advanced, allows the user to create complex programs quite quickly (but getting fast takes a year or so). Matthew Bouchard from the Pure Data community was working on a new GUI called Desiredata which would have improved on this with some support for complex keyboard-based manipulation of the graph, but that project has been abandoned. I would love to be proven wrong here, but I can't see it unless, perhaps, a structured text editor were created.

2. Text-based notations require you to keep a complex mental model in your head while working. It helps tremendously if the notation your using is in some way a visualization of the structure you're creating. Any notation system that does not prioritize this is not appropriate in my opinion.

3. Flow based programming practice, once you've already got a complex set of components of which you may not remember the details, involves a lot of 'pushing things around' and a lot of introspecting. A text-based notation should make it as easy as possible to rip-out a section of the graph and re-patch it, quickly try out a new route, hook up components for inspecting data flows or probing components for information about themselves, etc.. I think that no matter what notation you create, you'd have to be quite the text-editor ninja for this to be fast, but I could be shown to be wrong about this.

4. The one advantage of text is programatic symbolic manipulation. Block diagrams of highly specialized black boxes are not as amenable to such manipulations as the structure and elements we find in text-based lower-level programming languages, but programmatic manipulation of the graph is highly desirable in certains cases, namely where more than ten of the same object need to be connected in parallel (this comes up a lot in multi-channel audio systems – Jamoma provides a solution called a "multi-cable" and Max has the [poly~] object). Any notation that does not provide facilities for programmatic manipulation will have limited usefulness in this sense.

The fundamental issue, I believe, comes from the advantage of FBP that one can easily create complex "non-linear" flows. This is hard to represent in text because text is inherently linear. On a more constructive note, I think that the attempt to create a text-based block diagram notation that minimizes typing, clearly represents program flow, is amenable to rearranging blocks of text and that support programmatic manipulation of the graph is a highly worthwhile project. There are some disadvantages to visual languages and if the advantages of a text-based language could be made to outweigh those of a visual language, it could be quite useful.

The only notation that I know of that comes anywhere close to being usable for complex graphs is Faust's, which is quite elegant and also mathematically general (there's a paper from 2004 I think that proves that their block diagram notation can express any possible block-diagram). For those who are unfamiliar, it's notation that assigns operators to different types of function composition, much like the shell pipe operator. It also has natural support for subroutines by storing formulas in variables. It may still not be adequate, however. For instance I attended a workshop on Faust with Julius Smith about a year ago during which he mentioned that there was no good way to express feedback in the notation. This is a deal-breaker if it is still the case.

So, all of this is to say that after reading through some of the more theoretical posts on this list, I get the sense that those interested in implementing FBP systems would benefit immensely from using and studying the existing mature dataflow environments. At the moment the discussions seem to be very much at the level of theory and speculation with little knowledge of the practical realities of dataflow programming. Indeed once you start building complex systems in the dataflow style, you will become aware of a whole new class of problems that have received little attention on this list so far, but that should be addressed and brought to a more general audience, especially as the existing systems (Max, etc.) are now too ossified to evolve structurally.

[Ged Byrne]

Hi Morgan,

Thanks for sharing your value knowledge and experience, I really enjoyed your post.

I do however, feel that you have made a fundamentally false assumption, as expressed in this phrase:

how "FBP" (or dataflow programming as we call it) works in practice.

Here you are saying "Flow Based" and "Data Flow" are synonyms, two names for exactly the same thing.

I don't believe this to be true.  Hopefully Paul, who originated the phrase FBP, will be able to share his thoughts.  He is aware of Data Flow Programming, but believes the approach he has been pursuing under the FBP moniker to  be distinct and different.

Personally, I believe they key difference to be along an axis I will call "Comprensive vs Comprehensible".

I would argue that Flow Based Programming seeks to be Comprehensible above all else.  This may mean that the approach is only applicable to a certain class of problem.  This is not a problem, as long as the flow networks being created can be understood by everybody involved in trying to solve that class of problem - not just the technically adept.  The goal is the scenario described in the opening to Paul's book:

A meeting is called of all the people involved - not just programmers and analysts, but users and operations personnel as well. The essential logic of the program is put up on the wall, and the program designers walk through the program structure with the group. During the ensuing discussion, they realize that two new modules have to be written and some other ones have to change places. Total time to make the changes - a week!

http://www.jpaulmorrison.com/fbp/intro.shtml

Paul has developed FBP over decades from a practical perspective, and it has been optimised to support this type of situation.

To put this in a formal manner, if we imagine there is a problem space in which DESCRIBABLE is a set of all solutions that may described.  We also have a function COMPREHENSIBLE(X) where X is the amount of training required to comprehend a solution description.  COMPREHENSIBLE(0) would be all solutions that could be understood by a layman with no training.  COMPREHENSIBLE(MAX) would be the full set of DESCRIBABLE.  Flow based programming has the goal of achieving the largest possible result for the lower values of X.  Informally, it is accessible and comprehensible to people with little training.

Imagine we have to languages: F and D.  F is flow based and can only describe DESCRIBALE(F), a tiny subset of DESCRIBABLE.  However, every solution in DESCRIBABLE(F) is included in COMPREHENSIBLE(X) where X is a low value.  This would be fine, as long as DESCRIBABLE(F) was a useful subset.

D, a Data Flow language, is capable of describing all of DESCRIBABLE.  However, COMPREHENSIBLE(X) only returns values where X is high. ie. there is a steep learning curve.  Ideally, we would want D is be able to also support both high and low values of X, but this may not be possible.  I would argue that the best approach to discovering such a language, if it were possible, is to take the two different paths independently and see if any divergence emerges.  This means that while the Flow Based and Data Flow communities should remain distinct and separate.

For an analogy I would point to Adobe's photoshop and elements applications.  Photoshop is DFP, comprehensive and optimised to allow the properly trained professional creative freedom.  Elements is FBP, comprehensible and optimised to allow useful results with minimal training.

Of course, these are just my opinions, and I'd like to hear what others have to say.

Regards, 

Ged

[Morgan Sutherland]

Hello Ged,

Thanks for the reply and I'm glad you enjoyed my post – I was worried it might prove a bit inflammatory.

Terms

COMPREHENSIBLE(X) -> 'high/low comprehensibility'

DESCRIBABLE       -> 'describability'

Response

You're right that I conflated dataflow and FBP. I felt comfortable doing this after reading though some of the longer threads on this list and concluding that the systems being described had all of the same elements as the dataflow systems I had been using, just under different names. Having not read much of Paul's writing, I was not aware of the overriding emphasis on comprehensibility, which would certainly distinguish FBP as a "flow-based programming" paradigm with a particular philosophy or usage-scenario – one in which "learning curve" is minimized as much as possible (likely with considerable costs to comprehensiveness, at least at a certain level of abstraction) – whereas dataflow systems seem not to take a strong stance here. I'd like to take the stance that the approach you recommended of keeping FBP and dataflow separate may not be necessary.

A thought that immediately comes to mind is that maximizing comprehensibility at the FBP interface level may not inherently simplify systems, which means that as comprehensibility is maximized at one level of abstraction or description, other levels bear the burden of describability. To give an example, an FBP system that consists of modules written in C coordinated by a high-level graphical FBP language could result in a system that is highly comprehensible (low X) at the level of the FBP interface, but with emphasis only on the highest level of abstraction, there's nothing to say that the C code won't have a low comprehensibility. But this is actually a false dilemma.

In the dataflow systems that I'm familiar with, it's not necessarily the case that comprehensibility is sacrificed at the cost of describability. In fact, the programmer is tasked with optimizing the comprehensibility vs. describability equation. In a well designed dataflow application, the highest level of abstraction will be built, perhaps, in accordance with the principles of FBP – with comprehensibility as the primary concern – but at successive layers of abstraction where describability is desired, comprehensibility is sacrificed. (At the lowest level of abstraction, there is typically the abrupt jump to C code as in the previous example.)

So, I'm not sure I agree with the idea that FBP and dataflow should remain separate, lying at different points along the Comprehensiveness vs. Comprehensibility continuum. In my view, a well designed FBP/dataflow system should encourage maximizing comprehensibility at the highest level of abstraction, but would allow the program designer to manages the trade-offs differently at different levels of abstraction. Nesting is, of course, the tool that makes this possible, hence my mentioning it in the original post. Would not an appropriately general FBP system maximize flexibility rather than enforcing usage at a particular level of comprehensibility decided by the system designer ahead of time?

[Paul Morrison]

Hi Morgan and Ged,

Interesting discussion!  A couple of quick comments as I'm reading this at the airport:  Although DrawFBP is just the diagramming tool, it can actually generate runnable Java, C#, or NoFlo program. 

Now a DrawFBP diagram can always be expressed using Wayne Stevens' notation, e.g.

proc1(comp1) OUT -> IN proc2(comp2), proc2 OUT2 -> IN proc3(comp3), [etc.].. 

so the diagram and the text are exactly equivalent - except of course for xy coordinates...

Henri Bergius has suggested that we add a generator for this notation to DrawFBP - any other interested parties?

Some of the discussion seems to bear on whether diagrams or text are easier to edit.  Granted text is easier to move around, so we have to balance that facility with a sophisticated graphical editor.  On the other other hand, for me the text is harder to grok.  When you come down to it, visual vs. text is a  personal preference: most of the people I meet lean to visual, but I agree that a visual editor needs powerful visual transformation capabilities... We have made a start on that with the Enclosure feature of DrawFBP (thanks, Bob!), but we could certainly go further.  I also have a simple multiplexing feature, but totally agree that it needs to be made more powerful!

As against that, I have told the story of Chuck before - who built a 200-node network, using the stepwise refinement function in FBP (the DFDM implementation specifically) without ever drawing a single picture!  That's just the way his mind works!  BTW IMO there hasn't been enough discussion about stepwise refinement and how it ties in with FBP...

Happy Easter, everyone!

Paul

PS Ged, I need to study your answer more carefully - hopefully early next week.

--
http://jpaulmorrison.blogspot.com/

[ifknot]

Hello Morgan, Ged and Paul,

I don't think Morgan's view is at all inflammatory, simply correct.

I can can accept implicit assumption of FBP as an example of dataflow
programming at the non-triggered large granular end of the spectrum.

I agree they're not synonymous substitutions, FBP is a model of the
dataflow paradigm.

Consequently I'm surprised Ged (as proxy for Morrison himself) is
trying to divorce FBP from dataflow.

How can you say FBP is not a DAG of CSPs?

Further to that, I accept that Morrison developed FBP separately in
the early 70s but its nomenclature shares somewhat with Hoare's CSPs
of '78 and implements his proposed 'interpose a chain of buffers'.

I appreciate that Hoare's original paper was a road map for a language
that ultimately became Occam it is at one end of your proposed (but
undefined) "comprehensibility" but several papers have shown DAGs
derived from Occam and DAGs of component nodes with connection edges
can easily be be built visually, hence 'visual programming'

Witness the success of (the somewhat anachronistically named nowadays)
LabView.

But to me what is really special is that we have the person that was
involved at the beginning still around!

So come on Paul...
1. Why are you trying to divorce your semantics from dataflow?
2. Were you influenced by Hoare? (I read both versions of your book on
FBP's IBM origins)
3. Isn't FBP a methodology for the underlying dataflow paradigm
implemented as buffered CSPs?

regards and respect

Jeremy

On Apr 8, 1:38 am, Morgan Sutherland <skiptra...@gmail.com> wrote:
> Hello Ged,
>
> Thanks for the reply and I'm glad you enjoyed my post – I was worried it
> might prove a bit inflammatory.
>

> *Terms*
> *
> *

> COMPREHENSIBLE(X) -> 'high/low comprehensibility'
> DESCRIBABLE       -> 'describability'
>

> *Response*

>
> You're right that I conflated dataflow and FBP. I felt comfortable doing
> this after reading though some of the longer threads on this list and
> concluding that the systems being described had all of the same elements as
> the dataflow systems I had been using, just under different names. Having
> not read much of Paul's writing, I was not aware of the overriding emphasis

> on comprehensibility, which would certainly distinguish FBP as *a** *"flow-based

[Ged Byrne]

Jeremy,

To be clear here, my statements have been caveated as purely my own opinion.  There is no way that I can taken as a proxy.  On both occasions I have said that I look forward to hearing Paul's opinion.  Paul's only response is that he wants to take the time to read my comments before responding.

This same issue has also been raised on Wikipedia:  http://en.wikipedia.org/wiki/Talk:Flow-based_programming#Merge_discussion.

My understanding of what Dataflow programming is probably incorrect.  Could you point me to the official definition of what it is, so that I can easily distinguish between what is and isn't dataflow?

Regards, 

Ged

[Paul Morrison]

Hi Jeremy,

Ged has just answered your post, and I agree that I also would like to
see the official definition of dataflow. If we use it to denote all
approaches in which data can be said to "flow", it has to include
hardware, software, and indeed a sizable chunk of the real world. If
someone wants to try to untangle all the different dataflow paradigm
variations, s/he is welcome to try! I think Ged's dimensions of
comprehensibility and describility could be a useful way to organize
the concept space, but I wouldn't know how to position different
systems within that space. If you read my book, esp. Chap. 27 of the
new edition, you will realize that I essentially just threw up my
hands, and settled for giving thumbnail sketches of a number of what I
considered related systems. I have been told that I missed a lot, and
of course more are sprouting every week!

That said, 1) I don't believe I ever tried to separate FBP from
dataflow - in fact the oldest implementations that I worked on used the
term "dataflow" (with or without a separating blank), but we later
switched to "FBP" just because "dataflow" was so broad. I believe the
term is used nowadays more to describe hardware implementations - but I
may be wrong...?

2) I started with IBM in England, and once heard Hoare speak (it must
have been before 1964, as I left the UK then), but IIRC it was about
functional programming, not CSP. CSP was one of the concepts I ran
across _after_ I "discovered" FBP, and then started searching the
literature for similar concepts. My strongest influence in the very
early days was my experience with simulation languages - again described
in my book - the early descriptions of CSP seemed to me to be less
powerful than FBP - but I may have been wrong about that too :-)

2a) I have a couple of terminology quibbles: a) CSP apparently stands
for "Communicating Sequential Process_es_", so I have a little trouble
with "DAG of CSP_s_". Do you mean "DAG of Sequential Processes"? b)
FBP graphs can be, and often are, cyclic, so I guess we would have to
say "Directed Graph of Sequential Processes" - do the other Group
members think this is a helpful/useful description?

3) Can't say I understand this one - is it covered by the above points?

Regards,

Paul

[Ged Byrne]

Hi Morgan,

I mentioned comprehensibility as a way of showing that sometimes it
might be desirable to have a language that cannot describe non-trivial
tasks because of it's accessibility. The success of the original HTML
is a good example. It was inferior to the existing language such as
TEX, RTF and SGML yet it became ubiquitous and led to the development
of a XML and CSS.

Are there any good example languages that describing graphs that you
would recommend somebody consider before create their own?

Thanks,


Ged

On Apr 8, 1:38 am, Morgan Sutherland <skiptra...@gmail.com> wrote:

> Hello Ged,
>
> Thanks for the reply and I'm glad you enjoyed my post – I was worried it
> might prove a bit inflammatory.
>

> *Terms*
> *
> *