I agree with Mike that conceptually, dataflow is a lot of what digital programming "does". And I've investigated how to apply dataflow to some depth and found t

I agree with Mike that conceptually, dataflow is a lot of what digital programming "does". And I've investigated how to apply dataflow to some depth and found that there are three thorny issues: 1. Digital logic is special: you want a logic coding syntax and often some additional abstraction like a FSM; manipulating little logic gate nodes in the flow graph is too fine-grained and doesn't lend itself to describing something like a network protocol. (On the other hand, it might make sense to compile down to that representation at code generation time.) 2. Addressing data is special: finding out "where state is" to pluck it out for processing, and to subsequently store it, is consistently more complicated than dereferencing a pointer, and motivates the complexity of database engines, IP addressing, etc. There are varying degrees of data binding, layers of caching, etc. This is a missing piece of the puzzle that hinders dataflow from being the obvious choice for any given scenario. 3. Bounded buffers are an important engineering detail: a dataflow language that lets you dump an unlimited amount of data into a node and push "start" is a pleasant abstraction, but does not properly express the hardware bottlenecks that motivate parallelism. Morrison FBP gets this aspect right, while many other approaches bury it, which imperils them later.