5 ms·

One of the main issues with Flow-Based Programming is often while it optimizes generally in the opposite direction of Functional-Programming (Currying vs. Topol

One of the main issues with Flow-Based Programming is often while it optimizes generally in the opposite direction of Functional-Programming (Currying vs. Topological Sorting I.E.: Execute when needed vs. Execute as soon as possible) is that you tend to lose control of your software. While I'm not suggesting a purely imperative approach, to a certain degree gains can be had in an imperative context over either Functional/Flow Programming via in depth knowledge of OS/Hardware processes and are generally NOT developer fast/friendly. From a personal stand point Flow-Based Programming is amazing for concurrency since it lets you see where you can use threads/processes. As which sections of code are less attached to the rest.

falcolas 12y ago
> it optimizes generally in the opposite direction of Functional-Programming Really? It strikes me as exactly the opposite - the output of each discrete component is solely dependent on its input. There is no shared state between components, only what is passed between them.
- valarauca1 12y ago
  Your addressing the platform specific solution not the global problem I am. If you build a compiler that uses Flow Based programming without dipping into imperative blocks (very possible, and they exist). You get the problems I describe.
  - falcolas 12y ago
    Flow based programming actually has quite a bit in common with purely functional programming, in that the individual processes are generally stateless; their output depends solely on their input. The fact that the individual processes might be written in an imperative language simply doesn't matter at this point, so long as they always produce the same output for any given input. This is not true for all FBP processes obviously - there exist processes which read to and write from file handles, but much like the popular FP languages, these "tainted" processes are contained and separated from the remaining portions of the program via their connections to other processes. Most of the non-functional "programming" in Flow based programs actually occurs at the level where you are composing the connections between processes (be that the GUI, or in a hand-written method which makes the connections). One additional benefit of FBP which it shares with traditional FP programs is that they are capable of exhibiting "lazy" execution properties through the application of back pressure - by limiting how many packets of data a given connection can contain, you create a program which consumes only enough content from any given generator to keep the entire system occupied. Now then, can these abstractions break down if you start digging into the implementations of individual processes? Of course. It's not turtles all the way down, after all. Then again, all FP languages which run on Von Neumann based architectures suffer this problem. They all get compiled down to imperative machine code, and are all subject to the same state interruptions as every other program.
    - valarauca1 12y ago
      >Most of the non-functional "programming" in Flow based programs actually occurs at the level where you are composing the connections between processes (be that the GUI, or in a hand-written method which makes the connections). This is false, there are entire languages that do line by line compilation via Flow Based Programming. >One additional benefit of FBP which it shares with traditional FP programs is that they are capable of exhibiting "lazy" execution This is blatantly wrong and the main thing I was trying to express. Flow Based Programming is based off a topographical analysis of the code body. Which is a analysis of object dependencies (where a dependency is code that must be executed before the object (code) in question can be run). Meaning objects are executed in the order in which they have the least number of dependencies. This means one off sections of code, that do not necessarily need input from external, or exist independent of otherwise coherent processes he processed first. For example (Example 1) Path p = resolve_path(); if(something_happened()) { FP fp = open(p, "rw); write(fp, "logloglog"); close(fp); } This above code is bad, because path P is always resolved, regardless of error state. A Currying analysis (lazy evaluation) will change this flow via lazy evaluation (or should ideally): (example 2) if(something_happened()) { Path p = resolve_path(); FP fp = open(p, "rw); write(fp, "logloglog"); close(fp); } A topological flow based compiler will prefer path P be constant. It will prefer example 1, to example 2 every time (if its given example 1 as base code). And likely ensure that path P is solved for absolutely first in a function AS resolve_path() depends on no code being executed before it. This is the flaw in most flow based programs. Is they don't care errors like this, and when the errors do exit, they optimize for them to be more apparent. :.:.: This is what I mean by a topographical analysis being the opposite of a Currying analysis. They group code differently, in almost an opposite fashion. Curry trys to group code by purpose. Topological by how much code has to be executed before it. Both have their uses.

falcolas 12y ago

> it optimizes generally in the opposite direction of Functional-Programming Really? It strikes me as exactly the opposite - the output of each discrete component is solely dependent on its input. There is no shared state between components, only what is passed between them.

valarauca1 12y ago
Your addressing the platform specific solution not the global problem I am. If you build a compiler that uses Flow Based programming without dipping into imperative blocks (very possible, and they exist). You get the problems I describe.
- falcolas 12y ago
  Flow based programming actually has quite a bit in common with purely functional programming, in that the individual processes are generally stateless; their output depends solely on their input. The fact that the individual processes might be written in an imperative language simply doesn't matter at this point, so long as they always produce the same output for any given input. This is not true for all FBP processes obviously - there exist processes which read to and write from file handles, but much like the popular FP languages, these "tainted" processes are contained and separated from the remaining portions of the program via their connections to other processes. Most of the non-functional "programming" in Flow based programs actually occurs at the level where you are composing the connections between processes (be that the GUI, or in a hand-written method which makes the connections). One additional benefit of FBP which it shares with traditional FP programs is that they are capable of exhibiting "lazy" execution properties through the application of back pressure - by limiting how many packets of data a given connection can contain, you create a program which consumes only enough content from any given generator to keep the entire system occupied. Now then, can these abstractions break down if you start digging into the implementations of individual processes? Of course. It's not turtles all the way down, after all. Then again, all FP languages which run on Von Neumann based architectures suffer this problem. They all get compiled down to imperative machine code, and are all subject to the same state interruptions as every other program.
  - valarauca1 12y ago
    >Most of the non-functional "programming" in Flow based programs actually occurs at the level where you are composing the connections between processes (be that the GUI, or in a hand-written method which makes the connections). This is false, there are entire languages that do line by line compilation via Flow Based Programming. >One additional benefit of FBP which it shares with traditional FP programs is that they are capable of exhibiting "lazy" execution This is blatantly wrong and the main thing I was trying to express. Flow Based Programming is based off a topographical analysis of the code body. Which is a analysis of object dependencies (where a dependency is code that must be executed before the object (code) in question can be run). Meaning objects are executed in the order in which they have the least number of dependencies. This means one off sections of code, that do not necessarily need input from external, or exist independent of otherwise coherent processes he processed first. For example (Example 1) Path p = resolve_path(); if(something_happened()) { FP fp = open(p, "rw); write(fp, "logloglog"); close(fp); } This above code is bad, because path P is always resolved, regardless of error state. A Currying analysis (lazy evaluation) will change this flow via lazy evaluation (or should ideally): (example 2) if(something_happened()) { Path p = resolve_path(); FP fp = open(p, "rw); write(fp, "logloglog"); close(fp); } A topological flow based compiler will prefer path P be constant. It will prefer example 1, to example 2 every time (if its given example 1 as base code). And likely ensure that path P is solved for absolutely first in a function AS resolve_path() depends on no code being executed before it. This is the flaw in most flow based programs. Is they don't care errors like this, and when the errors do exit, they optimize for them to be more apparent. :.:.: This is what I mean by a topographical analysis being the opposite of a Currying analysis. They group code differently, in almost an opposite fashion. Curry trys to group code by purpose. Topological by how much code has to be executed before it. Both have their uses.