Talk:Dataflow programming

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)[reply]

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 142.167.69.62 19:43, 3 October 2006 (UTC)[reply]

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)[reply]

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?