3 ms·

Flow based programming is basically functional programming. It feels like a redefinition of a style of programming that's already heavily established.

yellowapple 7y ago
I'd say it's more of a potential application of functional programming - that is, you could* certainly use functional programming techniques/languages to implement flow-based programming, but functional languages are not automatically flow languages by merely existing. * But this is not strictly necessary. See also: Unix pipes, which fit the definition of flow-based programming while being possible - and in fact frequently done - with very-much-not-functional languages both implementing the individual steps and connecting them together.
- crimsonalucard 7y ago
  It looks like flow based programming is exactly the same thing as functional composition. Can you illustrate to me how these two concepts are disparate? I ask because if they are one in the same, then because the only way to link functions in functional programming is through function composition than functional programming is flow based programming.
  - kazinator 7y ago
    Flow-based programming instantiates numerous processes that are inherently stateful: they sit in a loop performing I/O operations: they read packets from input ports, transform them, and put them into output ports. The system as a whole has state: which packets are now being processed where. The ports represent stateful queues which buffer the packets. There is a pure functional view in that a pipeline of processes looks like a functional transformation. Just like we can regard "find . | grep | sort" as functional, ignoring all the grotty procedural C with I/O, buffering and all sorts of mutation. In Morrison's Flow-Based Programming book (which I happen to have in some storage cabinet somewhere) there are explicitly stateful examples, such as nodes which treat information packets (IP's) as syntactic tokens, doing parenthesis matching and such.
  - yellowapple 7y ago
    > It looks like flow based programming is exactly the same thing as functional composition. You can do flow based programming by composing functions, but - like I mentioned in my previous comment - it is possible to accomplish without any sort of functional programming at all (unless you consider Bash and Perl and C to be functional programming languages, of course!). > Can you illustrate to me how these two concepts are disparate? Say you have a connection between three elements in the flow, like so: step1 -> step2 -> step3 Each of these steps could be defined functionally (assuming that the maps read lazily): step1 = [stream of digits of pi] step2 = map { _ * 2 } step3 = map { _ / 2 } flow = step3 step2 step1 # map [ map [3 1 4 ...] { _ * 2 } ] { _ / 2 } Or they could be done procedurally: step1 = while [read digit from digits of pi] { write [digit] to stdout } step2 = while [read input from stdin] { write [input * 2] to stdout } step3 = while [read input from stdin] { write [input / 2] to stdout } flow = step1 | step2 | step3 # each digit -> digit * 2 -> digit / 2 With the pipe effectively defined as follows: | = spawn left; spawn right; while [read input from left] { write input to right } The key thing here, though, is that whether the underlying language is procedural or functional or whatever has very little relevance; what actually matters is that each of those steps can run concurrently, continuously listening for new inputs and sending new outputs. The functional approach does this by lazily reading values from a sequence. The procedural approach does this by more explicitly running the three loops concurrently (whether with preemptive processes/threads or via coroutines / green threads). This all assumes there ain't any branches in that flow graph, though; it gets a lot harder to represent a branch flow graph through functional means (not impossible, but most functional languages that delve into this sort of thing typically use Erlang-style actors and message passing instead of trying to represent this directly with function composition), while in the procedural case it's just deciding which output stream to use.
    - crimsonalucard 7y ago
      None of your steps are changing state. They are essentially functional in terms of composition. The sibling commenter had a better example of a tokenizer which changes it's own state on every input.
      - 7y ago

yellowapple 7y ago

I'd say it's more of a potential application of functional programming - that is, you could* certainly use functional programming techniques/languages to implement flow-based programming, but functional languages are not automatically flow languages by merely existing. * But this is not strictly necessary. See also: Unix pipes, which fit the definition of flow-based programming while being possible - and in fact frequently done - with very-much-not-functional languages both implementing the individual steps and connecting them together.

crimsonalucard 7y ago
It looks like flow based programming is exactly the same thing as functional composition. Can you illustrate to me how these two concepts are disparate? I ask because if they are one in the same, then because the only way to link functions in functional programming is through function composition than functional programming is flow based programming.
- kazinator 7y ago
  Flow-based programming instantiates numerous processes that are inherently stateful: they sit in a loop performing I/O operations: they read packets from input ports, transform them, and put them into output ports. The system as a whole has state: which packets are now being processed where. The ports represent stateful queues which buffer the packets. There is a pure functional view in that a pipeline of processes looks like a functional transformation. Just like we can regard "find . | grep | sort" as functional, ignoring all the grotty procedural C with I/O, buffering and all sorts of mutation. In Morrison's Flow-Based Programming book (which I happen to have in some storage cabinet somewhere) there are explicitly stateful examples, such as nodes which treat information packets (IP's) as syntactic tokens, doing parenthesis matching and such.
- yellowapple 7y ago
  > It looks like flow based programming is exactly the same thing as functional composition. You can do flow based programming by composing functions, but - like I mentioned in my previous comment - it is possible to accomplish without any sort of functional programming at all (unless you consider Bash and Perl and C to be functional programming languages, of course!). > Can you illustrate to me how these two concepts are disparate? Say you have a connection between three elements in the flow, like so: step1 -> step2 -> step3 Each of these steps could be defined functionally (assuming that the maps read lazily): step1 = [stream of digits of pi] step2 = map { _ * 2 } step3 = map { _ / 2 } flow = step3 step2 step1 # map [ map [3 1 4 ...] { _ * 2 } ] { _ / 2 } Or they could be done procedurally: step1 = while [read digit from digits of pi] { write [digit] to stdout } step2 = while [read input from stdin] { write [input * 2] to stdout } step3 = while [read input from stdin] { write [input / 2] to stdout } flow = step1 | step2 | step3 # each digit -> digit * 2 -> digit / 2 With the pipe effectively defined as follows: | = spawn left; spawn right; while [read input from left] { write input to right } The key thing here, though, is that whether the underlying language is procedural or functional or whatever has very little relevance; what actually matters is that each of those steps can run concurrently, continuously listening for new inputs and sending new outputs. The functional approach does this by lazily reading values from a sequence. The procedural approach does this by more explicitly running the three loops concurrently (whether with preemptive processes/threads or via coroutines / green threads). This all assumes there ain't any branches in that flow graph, though; it gets a lot harder to represent a branch flow graph through functional means (not impossible, but most functional languages that delve into this sort of thing typically use Erlang-style actors and message passing instead of trying to represent this directly with function composition), while in the procedural case it's just deciding which output stream to use.
  - crimsonalucard 7y ago
    None of your steps are changing state. They are essentially functional in terms of composition. The sibling commenter had a better example of a tokenizer which changes it's own state on every input.
    - 7y ago