Tim Bray has started (another) interesting concurrency discussion over at his blog. While, to me, he was originally "that XML guy", I soon learned that cares a lot about concurrency. One of the big things he started was the "Wide Finder Project", a language comparison with submission by lots of people. As far as I can tell, his interest in performance was sparked by a desire to find out how Erlang -- which at the time had been touted as the next big concurrency language -- really performs. Since then, he has also frequently mentioned Scala and Haskell as interesting languages.

I guess this newest venture is an attempt to cover the issue in more breadth and amongst other, he also mentioned tuplespaces and dataflow approaches in his laundry list of approaches. Anybody who has talked to Sebastian recently knows that he is fond of Tuplespaces and I've talked people's ears off about dataflow, so you can already guess that I liked them making his list ;-)

However, while he mentioned them, he immediately dismissed them, because he thinks they are not in widespread use. Thats what I also though until about a year back, when I started reading more dataflow papers. Since then I have been constantly amazed at how many places the approach can be found. However, these uses are often outside of the public view, which may be why they are not widely known. Anyway, I think that is far from "little", so I weighed in with a comment, to point out the widespread use of dataflow in (amongst others) the signal processing world.

One of the impressions I got during my exploration of dataflow is that lots of people are doing dataflow in some sense, they just don't call it that way. Still other people use some of its ideas (like reactivity), but not others. In a way, that may be the real issue -- dataflow is so general that lots of things can be done with it and people don't see it as a coherent concept. Well, maybe it isn't, but there is still a lot to learn there, methinks.

In a way, that's why I proposed the term "event-flow" for our fts approach, because I thought that data-flow was too broad and because we take a few ideas from the event-based-integration side. Funnily enough, Sebastian also came up with term (independently) for his recent talk at the EPTS symposium, so maybe there is something to it.

I'll be keeping track of Tim's discussion points and maybe we can even get our concepts promoted a little bit more ;-)