Dataflow Programming

A programming paradigm in which computation is modelled as a directed graph (which may or may not contain cycles), the nodes of which are either data sources (producers of data), data sinks (consumers), or "processing elements" which compute some function; and the arcs of which represent dataflow between nodes. May be synchronous (driven by some master "clock" which causes processing nodes to chunk through one datum per clock cycle) or asynchronous (where nodes operate whenever there is data at their input vertices--the push model--or requests for data upon their outputs--the pull model).

Kind of like electrical circuit design, but at a larger scale. (And without the nasty analog properties of electrical circuits--parasitic impedances, fan-out problems, etc.)

See also:

• FlowBasedProgramming
• PipesAndFilters

Languages supporting DataflowProgramming:

• PrographLanguage
• GeeLanguage
• VplLanguage
• BounceLanguage
• CalLanguage
• Unix Shell (PipesAndFilters)

---

Moved from DataFlowSystems:

Data Flow Systems are quite powerful. They are often used in hard real time problems. The basic data flow conceptual elements are the process, the file, and the data flow. Sources and Sinks are privileged processes at the external environmental boundaries of the system. The bible to me on this approach is TomDeMarco's book on SASS which was published about 1975 or thereabouts. Great book!

I have always liked an architecture which I call IPO-Net, an IPO-Net is just a Data Flow Architecture -- I used to program this way before there were disk files. Everything had to go from and to tape. So an IPO was an input tape, a process and an output tape. This is a PipesAndFilters kind of thing where the process can be interrupted and archived at any stage. It is to me a neat way to think about computational architecture (maybe I'm just showing my age) because it is applicable across such a broad range of hardware architectures and can be made so forgiving.

I used it to create a tool-set for a system called The Flyover System which was a processing toolset for analyzing airborne radio leakage data collected over cable television systems to verify compliance with FCC leakage regulations. It was a simple and forgiving system which was easy to use, to extend, etc. --RaySchneider

---

From my point of view, DataFlowSystems are the same as PipesAndFilters.

--RalphJohnson

I think that DataFlowSystems may be more general than PipesAndFilters. (Consider whether the data flow is "pushed", "pulled", "clocked", or some hybrid.

---

Computers (processors, controllers) themselves might be considered dataflow parts as might many other digital circuits. Consider the ALU, instruction pipelines, DMAcs and interrupts, USARTS and other peripherals that use various registers to shift data in and out of processing elements.

---

Lotus-style macros?

Spreadsheets are closer to FunctionalProgramming than any of the other paradigms.

I would describe them primarily as a branch of ConstraintModels, but that doesn't contradict your assertion, as constraints are a common technique in FP.

ProgrammingParadigm