Arc Forumnew | comments | leaders | submitlogin
3 points by rocketnia 4099 days ago | link | parent

What's your personal background like? When I Google your name I mainly get a bunch of news articles about this Kickstarter. :-p (Edit: Oh, whoops. You have a bio on Kickstarter after all. http://www.kickstarter.com/profile/1712125778)

What would you say the difference is between "flow-based programming," "reactive programming," and "dataflow programming"? It sounds like you're making useful distinctions but that I just don't know what they are.



3 points by mattcarkci 4099 days ago | link

From my experience, the term "Dataflow programming" is an overarching concept for both Flow-Based Programming and Reactive Programming.

I use the term "Pure Dataflow Programming" in reference to the original idea put forth by Bert Sutherland's paper "The On-line Graphical Specification of Computer Procedures" and others. It is characterized by fine grain operations (small operations like add or subtract) and the assumption that dataflow concepts will be employed for all levels of an application.

Flow-Based Programming takes the Dataflow concepts but says that the nodes (aka components) should be programmed using our current, sequential, control-flow programming languages. The Dataflow graph is a layer above and it controls the execution of the nodes.

Reactive Programming is a newer term. I use it to mean Dataflow using the push model (nodes only execute when data is pushed to it). It is "reactive" to changing data.

There is a tower of babble in respect to Dataflow terminology because we haven't yet defined a common meaning for all the terms. These are my definitions for the terms but everyone seems to define things slightly different.

I will have a chapter in the book that explains all the terms and their common synonyms.

As Dataflow concepts are just now starting to come to the attention of the masses, we don't have any consensus on the best, or most common, Dataflow implementation architecture. So the book will cover all the tiny variations of Dataflow architectures and compare them to each other for their pros and cons.

If you're old enough to remember when OOP started to hit the front pages, you may remember the debate between prototype based OOP and class based OOP. For the most part, class based OOP is the most common model by far. Thus, books now only cover class based OOP. Unfortunately for me, Dataflow programming has not reached that maturity level yet so I try to cover all variations and let the reader decide what is best.

-----