I understand the basics of dataflow programming and have encountered it a bit in Clojure APIs, talks from Jonas Boner, GPars in Groovy, etc. I know it’s prevalent in languages like Io (although I have not studied Io).
What I am missing is a compelling reason to care about dataflow as a paradigm when building a concurrent program. Why would I use a dataflow model instead of a mutable state+threads+locks model (common in Java, C++, etc) or an actor model (common in Erlang or Scala) or something else?
In particular, while I know of library support in the languages above (and Scala and Ruby), I don’t know of a single program or library that is a poster child user of this model. Who is using it? Why do they find it better than the other models I mentioned?
I have a wrong example, too. It does not implement a clean actor model, and it has no concurrency issues, but it uses DF architecture, and extremly popular: any spreadsheet software (e.g. MS Excel).
When you modify a cell, it sends “recalculate” signal to the cells which have reference to it. Altough, when you are working with a sheet, which becomes bigger and bigger, you can feel the real taste of the dataflow programming – the focus of the work will change:
If we realise, that formulas are components, and references are messages, we get the usual way of dataflow programming: first, we’re creating some components, then we’re building a dataflow graph with them. If components are too big, we split them into smaller ones. Finally, we’re picking a visualization component for an eye-candy result presentation.