Reactive programming vs. Dataflow programming
I'm wondering what's the exact difference beetween both pardigms as reactive programming is "a programming paradigm oriented around data flows and the propagation of change"? —Preceding unsigned comment added by 18.104.22.168 (talk) 20:46, 19 July 2009 (UTC)
- As I understand it, reactive programming has the adittional requirement of allowing the system inputs to change at any time; then the program will update itself through the whole data flow by propagating the effect of these changes.
- This is not necessary in plain dataflow programming; I've seen dataflow languages that still require the input data to be defined as a whole before the program starts execution, and which control flow is strictly deterministic with a well-defined sequence of steps - i.e. the only difference with an imperative program is the visual syntax making the dataflow explicit and the control state implied by the program structure, but the execution semantics are finally the same. Diego (talk) 11:50, 15 September 2009 (UTC)
Max paradigm languages are not dataflows
I removed from the dataflow languages examples list Max, Pure Data and VVVV. Because they are not Dataflow Languages.
Please, read the bellow arguments and say whether you agree or not.
According to Paul G. Whiting definition in A History of Data-Flow Languages 
"The data-flow model has the single-assignment property. Values are data tokens that are transported from their producing node to the node that consumes them; there is no concept of a variable with a state that can be arbitrarily updated at a later time. In data-flow, identifiers may be used to name these data tokens. Such identifiers are thus either undefined (not yet produced) or carry a single unique value; they cannot be updated."
That's not true for Max paradigm as Miller Puckette state in "Combining Event and Signal Processing in the MAX Graphical Programming Environment" 
"MAX is not a dataflow language; the boxes which make up a patch usually contain some local state. Dataflow's independence of the order in which the inputs to an operation become available cannot be achieved here. On the other hand, MAX's object-oriented approach is much more appropriate for systems which must respond to external requests for action. In this scenario which is typical of live human/machine interaction, the order in which transactions occur is often significant. A violin should be tuned before playing it, not after, for best results."
- An argument for listing languages such as MAX
From that same Whiting article:
"Second, the efficient implementation of certain operations, particularly those associated with creating and manipulating large data structures, is fundamentally difficult in a pure data-flow environment. We thus consider that data-flow languages are those which, however their semantics are defined, have a strong favor of the data-flow model, albeit as modified by the evolutionary process. We also note that, although the purity of the original model of data-flow has been sacrificed, most language designers have sensibly attempted to preserve equivalent semantics to the single-assignment property."
In particular, I would point out "data-flow languages are those which, however their semantics are defined, have a strong favor of the data-flow model", and "most language designers have sensibly attempted to preserve equivalent semantics to the single-assignment property" (not all). With this in mind, it would seem reasonable to consider MAX a dataflow language.
Additionally, the Puckette article came before the Whiting article, so it was unlikely to use its more progressive definition of dataflow (admittedly, Whiting does not mention MAX in the survey paper). Also, since both of these articles are quite old, unless there are newer publications that weigh in on this issue I suggest we give adequate room for "modified by the evolutionary process" and list languages that "have a strong favor of the data-flow model" as dataflow languages, as per the definition above.
DancingHacker 19:18, 7 July 2007 (UTC)
Data-flow languages are all visual?
Surely this article is erroneous in saying that data-flow languages are all visual? The (first?) data-flow language Lucid has no visual environment for programming.
Riftor 08:24, 7 May 2006 (UTC)
Some points, which I will address should I get the time:
- The parallellism that dataflow languages inherently support is not as useful as it seems; in practise, the parallellism is too finely grained for modern multicomputer architectures, and the overhead of managing dataflow at runtime is excessive.
- Please stop spreading false information. There is evidence to the contrary in J. Paul Morrison's book http://www.jpaulmorrison.com/fbp/ where he has data on this and also that he's had software using FBP that is still in use from 30 years ago by major banks. In any case, if the threading model isn't up to par on a specific machine, you can rewrite it to use larger granularity. It's programmer and implementation dependent. FBP makes this MUCH easier to handle. Why you would spead misinformation like this is beyond me. Just because you used a bad implementation doesn't mean it can't be changed. -V 22.214.171.124 19:43, 3 October 2006 (UTC)
- Prograph was designed originally to be a visual programming language; it is a dataflow-based language as a side-effect, based on the fact that the dataflow paradigm lends itself well to the visual design space (I know this because Dr. Philip Cox, the maker of Prograph, is an instructor of mine).
Penumbra 2k 21:54, 4 December 2005 (UTC)
Can the following line -- "On machines with a single processor core where an implementation designed for parallel operation would simply introduce overhead, this overhead can be removed completely by using a different runtime." be explained better? It is not clear to me what the last part of the sentence means -- i.e. how does using a different runtime(?) remove overhead?
Maybe this will help with the discussions here?
Hey guys. I'm new to Wikipedia, so forgive me if I'm not fully P.C. on the guidelines.
We built a dataflow language, compiler and engine all based on J2SE and XML scripting. The dataflow graph visualizer is based on Eclipse. It came out of "stealth" last week. It's free for development use and free for any non-commercial use.
It is massively parallel in a shared memory environment. We ran some benchmarks both in labs and at Fortune 500 data processing companies. It short -- it works. So perhaps some disagreement on what is possible and not possible can be based on the "state of the art" currently available in 2006/7 ??
Emilio 19:20, 6 December 2006 (UTC)EmilioB
What's the difference between dataflow languages and functional languages? The article seems to indicate that they're very similar; a comparison of these would be of great use to some readers who are looking for a general overview. —Preceding unsigned comment added by 126.96.36.199 (talk) 06:12, 25 March 2008 (UTC)
in the first paragraph of 'Properties of dataflow programming languages'the difference between imperative programming and daata flow programming is left a little bit vague
'Dataflow languages contrast with the majority of programming languages, which use the imperative programming model. In imperative programming the program is modeled as a series of operations, the data being effectively invisible. This distinction may seem minor, but the paradigm shift is fairly dramatic, and allows dataflow languages to be spread out across multicore, multiprocessor systems for free.' —Preceding unsigned comment added by 188.8.131.52 (talk) 12:23, 8 July 2008 (UTC)
- My understanding is that the primary difference has to do with execution order. Most functional languages still pretty much evaluate expressions in the order they appear in a function. Pure functional languages like Haskell can reorder and parallelize expressions inside pure functions, but inside a monad everything still executes serially. This means that if you want to parallelize code that uses mutable state or does I/O you need to use threads. In a dataflow language, all operations that don't have dependencies on each other can potentially be run in parallel. If there's a need to order certain operations (for doing I/O for instance) it's up to the programmer to specifically inform the language that those operations need to be ordered. Mask of Destiny (talk) 14:09, 21 October 2008 (UTC)
Adam and Eve
AviSynth scripting language seem to be a dataflow language even if it does not look like one. It has no control flow operations (i.e. : no if/while/for/goto,...). However, it has the ternary conditional operator ("?:", as in C), functions, and recursivity. It is designed so that data are computed only when needed (lazy evaluation). This is important since operations on video may take a lot of CPU time. AviSynth scripts are also good for parallel tasking, even if the current implementation doesn't take full advantage of this. —Preceding unsigned comment added by 184.108.40.206 (talk) 14:38, 12 December 2008 (UTC)
- Are you sure? It's not really what I think of as one. I'm not going to remove it though, because I'm not real sure. flarn2006 [u t c] time: 22:56, 15 July 2012 (UTC)
Clojure as a dataflow laguage?
Why Clojure is listed as a dataflow language? Does it have any specific language constructs supporting this paradigm? Otherwise we can list any functional programming language here :) Vzaliva (talk) 14:22, 19 March 2011 (UTC)