13 ms·

The state of Flow-based Programming

115 points by bergie 4y ago

debacle 4y ago
Flow-based programming is "the future" in the same way that Object-oriented programming was "the future" in the late 90s. If history is any evidence, in 10 years we will all be using some mix of evented/flow based GUI tool. Some people will complain that everyone else is wrong, the functional programming folks will claim they invented flow-based programming first, and we'll see everything that has been being reinvented every 3 years for the last 20 years reinvented again. And I look forward to it. This is just the way our industry is - new ideas + young energy crashing against institutional knowledge, slowly advancing the status quo.
- mountainriver 4y ago
  In 10 years all programming will be AI assisted and this stuff won’t matter much
  - Hedepig 4y ago
    This exactly. I am playing around with gpt-3, its trivial to build schemas using natural language, and building functions that interact with those schemas, also with natural language
    - papandada 4y ago
      Would love a blog post on your experiences
      - Hedepig 4y ago
        I'm not sure if I have the talent to write something worthy. But I can tell you that using the tech in this way makes me feel drunk on power.
dm319 4y ago
Interesting to see this come up, as I only recent came across Pure Data [1]. I find it surprising that the numerical programming languages aren't flow-based. R makes good use of pipes, and I guess it works a bit like flow-based programming, except that they are all are 1D segments of variable length, and no branches. Sometimes I think that Go's channels are bit a flow-like (though it is otherwise very much not functional!). If anyone knows of a flow-based programming add-on to R, I'd be very curious. [1] https://en.wikipedia.org/wiki/Pure_Data https://en.wikipedia.org/wiki/Pure_Data
- chaosprint 4y ago
  The counter in pd is pure elegance
ramboldio 4y ago
For Architects, Designers and Musicians, flow-based programming is a big deal: Rhino/Grasshopper, Touchdesigner or Ableton Max for Live are all great examples. More people should pay attention. Even if you know how to code in a general-purpose language, you won't beat the speed of these tools (for small to medium-sized programs, anyway).
- FormFollowsFunc 4y ago
  It's growing in popularity in 3D software. Blender, Cinema 4D, Maya and Vectorworks have added nodes in the last few years. Houdini, SoftImage, Generative Components (Bentley) and Grasshopper were early adopters. nTopology and Modo take a stack approach to parametric modelling. It looks less complicated but you quickly run into their limitations. Nodes were popular in compositing software in the 90s - Nuke, Flame, Shake. Code is better when the programme gets bigger but they're less scary for non-programmers to get into.
  - rcarmo 4y ago
    Sadly, Godot discontinued their visual scripting recently (which admittedly had a quite low level of abstraction and made some things cumbersome to create).
- dagw 4y ago
  Even if you know how to code in a general-purpose language, you won't beat the speed of these tools It isn't even an either or proposition in general. In grasshopper for example you can just drop in a Python on VB node anywhere in your flow and run arbitrary code before passing the output along. It is also really easy to write your own nodes in C# letting you wrap any arbitrary complex analysis and data transformation using any .Net library you want, into a simple node you (or anyone) can just drop into their own flow-based program.
- klabb3 4y ago
  I think the main issue for programmers is VCS, and the associated tooling like diffs. With git + code, you have an easy way to modularize, diff, collaborate and review. In these other professions, you mostly work alone or go through the painful process of working together on the same project. This shouldn't be impossible for flow-based tools, either by making them collab based (like figma) or by having multiple representations (declarative code and visual - possibly by having visual be read-only). Flow based programming already have a straightforward and imo excellent path for modularization (which is the only known way to deal with software complexity). I would love to see flow based programming combined with individual components written in conventional languages. Regular code is clearly superior for many tasks, so flow should be applied between components, and not be too granular. Another challenge is meta-programming. If you need to produce components at runtime, you would naively lose visualization and other benefits. So more research and idioms are needed to really present a coherent system that maintains a similar DX when that extra flexibility is needed. Still, I'm very bullish on medium-term applications of flow based programming within software design. At least for me, it has some absolute killer features; such as understanding existing systems, mapping to my mental model better and spotting bottlenecks and inconsistencies much earlier. I already use pencil-and-paper flow diagrams for software design, but resort to conventional code when implementing.
wodenokoto 4y ago
Are things like Apache Beam and Apache Airflow examples of flow based programming? What about Tensorflow and Pytorch?
- mikewarot 4y ago
  Upon first inspection, it appears that Beam and Airflow are types of flow based programming. >What about Tensorflow and Pytorch? Those are tools for describing, training, and executing neural networks. (I have used both)
tralarpa 4y ago
Flow-based programming is very old. Often in combination with visual programming languages, it has been used for a very long time in automation systems, data and signal processing systems, audio, etc. The problem with visual programming languages (the focus of the articles seems to be on them) is that they don't scale in size and complexity. For large projects, you end up with visualizations like the LabView one in the article. For complex projects, you try to tame the complexity by offering a textual language to program complex components, with the consequence that you are constantly switching between the two representations.
- zozbot234 4y ago
  Visual programming should be one of many ways of interacting with a codebase. Some software abstractions are inherently quite conducive to a visual representation, such as anything that can be understood as a monoidal category. (Ordinary dataflow is indeed one example of this, but there are others; and even the modeling of dataflow introduces some extra subtlety, which is barely acknowledged in OP) Others, not so much; and a textual representation might both be more compact and ultimately clearer.
  - 082349872349872 4y ago
    The usual algebraic textual representation is, after a fashion, also a visual representation. Compare how 'w § x § y § z' —or '(§ w x y z)' for the lisp weenies— brings together an operation and its arguments in a single visual chunk, to how in RPN there are many ways for the arguments and their operations to be arbitrarily separated in the textual stream.
  - agumonkey 4y ago
    Good point. Another thing is that program gets desugared into graphs anyway..
    - mountainriver 4y ago
      Yeah but the AST is super complex and you wouldn’t want to interact with it directly
smartmic 4y ago
DSPatch[1] is a pretty usable dataflow framework for C++ enthusiasts. [1] http://flowbasedprogramming.com/docs/html/index.html http://flowbasedprogramming.com/docs/html/index.html
z9znz 4y ago
I used a visual data analytics toolkit for several years to help big telcos reconcile switch vs billing data. The tool was very dated looking, but it was ideal for the specific tasks we were performing. I found the best use was as a discovery tool. Often a business would believe it knew its own processes and rules, but with large complex systems (often quite old software, especially on the billing side), it was very difficult for the companies to know if what they believed were the business rules were actually what was happening in their software. So we would work with the client to visually express these rules, in steps and phases, using visual flow-based development. It was kind of similar to REPL-based programming in that you could drop a node on the canvas, hook it up to a previous output, and run it immediately. Then you could inspect the outputs to see the result. Of course there were also UI features which made it very easy to get various details at a glance, such as number of elements on outputs with additional details on hover (min/max, avg, etc.) Being visual, it was also easier for non-technical clients to grasp what was going on. It was sort of a bridge language which allowed us to communicate with the client. Often the client would come up to speed with this representation and actually get involved in the building process. Eventually you have accurately modeled the business process, or at least what the process _should_ be. Then if the numbers coming out aren't right, you do additional analysis to identify the root causes. Then you build some following models which compensate for this to ensure the correct output. Finally, you have a formula of sorts which can then be implemented in other more production/repeatable code. On average, a client would recover $10 in lost revenue (due to billing errors) for every $1 they spent on our time. An unexpected side benefit of this process was that new observations could be made which might shape future business decisions. This was especially useful for new business models (such as design and implementation of early in-flight wifi services). Regarding model/diagram complexity, that was solved in the same way we solve complexity in text-based coding. You just organize details into sub-models, drilling down or stepping out to different views. One complex model might end up with a single node representation within a higher level model. I always wished we could have UI views like this on normal software projects to help in those times where your head gets lots in the complexity of dozens of modules and hundreds or thousands of functions (seeing the forest despite the trees, etc.)
chaosprint 4y ago
Very interesting topic for me. Thanks for posting this. As pointed out in other post, it's widely used in audio/music programming. My project Glicol(graph oriented live coding language) joins this list recently: https://glicol.org https://glicol.org I managed to use solely text based style for denoting audio graph. But often I am asked why I have no visual programming interface for it. I would be happy to listen to all the feedback from you at the repo: https://github.com/chaosprint/glicol https://github.com/chaosprint/glicol
- FractalHQ 4y ago
  Seems to be silent on iOS. Any idea why? Looking forward to checking this out at my computer later!
  - chaosprint 4y ago
    Which browser are you using? If I remember correctly, the audio on iOS devices requires iOS >= 14.5
- yboris 4y ago
  Mindblowing! Thank you for creating this (and for sharing the link!) The demo page is stellar: https://glicol.org/demo#ambienthouse https://glicol.org/demo#ambienthouse
soco 4y ago
The flow programming is for me at home in integrations. Middleware like Apache Camel, data pipelines like Jaspersoft or workflows like Activiti always offered an IDE with graphical representations of those flows - traditionally a bit kludgy maybe. The newer Ballerina cloud integration language from WSO2 offer this duality code-visual natively.
jcelerier 4y ago
A small issue with flow-based programming is that it often doesn't have a good way to represent time and sequencing over "human" time scales - the main project I work on, https://ossia.io https://ossia.io combines timeline and dataflow to solve this. It's mainly used by artists but I always wonder about the other potential use cases for it... if anyone has ideas :D
- di4na 4y ago
  Runbooks or any kind of ops agent would probably fit well. In particular something like a start/stop/init daemon At least in my mind. Hell even a deployment tool would probably fit some of that paradigm. It would ofc need some work to adapt it and maybe something like Crochet would make more sense but eh
DavidPP 4y ago
Node-RED is also fairly popular in home automation circles, but it's a generic tool that can be used for different purposes. For example, it can also be used to build chatbots. https://nodered.org/ https://nodered.org/
- riekus 4y ago
  Nodered is really awesome. I work in the Salesforce ecosystem where flow based programming is being pushed and adopted and always wish they would have adopted the nodered way of doing things.
- monkeydust 4y ago
  +1 suprised it wasnt mentioned. Use it heavily in home assistant to connect up devices that were never designed to talk to each other to do some interesting things.
abrax3141 4y ago
Seems like the analysis is missing functional programming, which is basically flow based.
- jeffreygoesto 4y ago
  Why is this comment being downvoted? The nodes of a flow graph (usually) are equivalent to pure functions. The graph represents chaining of those functions and the ports of the nodes are their type signatures. There is a comment in parallel that correctly states "getting down" is a gap or difficult. This maps to the fact that functional programming paradigms are easier to use higher up and deep down it somehow gets imperative on the way, and be it only in the compiler...

115 points by bergie 4y ago

Flow-based programming is "the future" in the same way that Object-oriented programming was "the future" in the late 90s. If history is any evidence, in 10 years we will all be using some mix of evented/flow based GUI tool. Some people will complain that everyone else is wrong, the functional programming folks will claim they invented flow-based programming first, and we'll see everything that has been being reinvented every 3 years for the last 20 years reinvented again. And I look forward to it. This is just the way our industry is - new ideas + young energy crashing against institutional knowledge, slowly advancing the status quo.

mountainriver 4y ago
In 10 years all programming will be AI assisted and this stuff won’t matter much
- Hedepig 4y ago
  This exactly. I am playing around with gpt-3, its trivial to build schemas using natural language, and building functions that interact with those schemas, also with natural language
  - papandada 4y ago
    Would love a blog post on your experiences
    - Hedepig 4y ago
      I'm not sure if I have the talent to write something worthy. But I can tell you that using the tech in this way makes me feel drunk on power.

dm319 4y ago

Interesting to see this come up, as I only recent came across Pure Data [1]. I find it surprising that the numerical programming languages aren't flow-based. R makes good use of pipes, and I guess it works a bit like flow-based programming, except that they are all are 1D segments of variable length, and no branches. Sometimes I think that Go's channels are bit a flow-like (though it is otherwise very much not functional!). If anyone knows of a flow-based programming add-on to R, I'd be very curious. [1] https://en.wikipedia.org/wiki/Pure_Data https://en.wikipedia.org/wiki/Pure_Data

chaosprint 4y ago
The counter in pd is pure elegance

ramboldio 4y ago

For Architects, Designers and Musicians, flow-based programming is a big deal: Rhino/Grasshopper, Touchdesigner or Ableton Max for Live are all great examples. More people should pay attention. Even if you know how to code in a general-purpose language, you won't beat the speed of these tools (for small to medium-sized programs, anyway).

FormFollowsFunc 4y ago
It's growing in popularity in 3D software. Blender, Cinema 4D, Maya and Vectorworks have added nodes in the last few years. Houdini, SoftImage, Generative Components (Bentley) and Grasshopper were early adopters. nTopology and Modo take a stack approach to parametric modelling. It looks less complicated but you quickly run into their limitations. Nodes were popular in compositing software in the 90s - Nuke, Flame, Shake. Code is better when the programme gets bigger but they're less scary for non-programmers to get into.
- rcarmo 4y ago
  Sadly, Godot discontinued their visual scripting recently (which admittedly had a quite low level of abstraction and made some things cumbersome to create).
dagw 4y ago
Even if you know how to code in a general-purpose language, you won't beat the speed of these tools It isn't even an either or proposition in general. In grasshopper for example you can just drop in a Python on VB node anywhere in your flow and run arbitrary code before passing the output along. It is also really easy to write your own nodes in C# letting you wrap any arbitrary complex analysis and data transformation using any .Net library you want, into a simple node you (or anyone) can just drop into their own flow-based program.
klabb3 4y ago
I think the main issue for programmers is VCS, and the associated tooling like diffs. With git + code, you have an easy way to modularize, diff, collaborate and review. In these other professions, you mostly work alone or go through the painful process of working together on the same project. This shouldn't be impossible for flow-based tools, either by making them collab based (like figma) or by having multiple representations (declarative code and visual - possibly by having visual be read-only). Flow based programming already have a straightforward and imo excellent path for modularization (which is the only known way to deal with software complexity). I would love to see flow based programming combined with individual components written in conventional languages. Regular code is clearly superior for many tasks, so flow should be applied between components, and not be too granular. Another challenge is meta-programming. If you need to produce components at runtime, you would naively lose visualization and other benefits. So more research and idioms are needed to really present a coherent system that maintains a similar DX when that extra flexibility is needed. Still, I'm very bullish on medium-term applications of flow based programming within software design. At least for me, it has some absolute killer features; such as understanding existing systems, mapping to my mental model better and spotting bottlenecks and inconsistencies much earlier. I already use pencil-and-paper flow diagrams for software design, but resort to conventional code when implementing.

wodenokoto 4y ago

Are things like Apache Beam and Apache Airflow examples of flow based programming? What about Tensorflow and Pytorch?

mikewarot 4y ago
Upon first inspection, it appears that Beam and Airflow are types of flow based programming. >What about Tensorflow and Pytorch? Those are tools for describing, training, and executing neural networks. (I have used both)

tralarpa 4y ago

Flow-based programming is very old. Often in combination with visual programming languages, it has been used for a very long time in automation systems, data and signal processing systems, audio, etc. The problem with visual programming languages (the focus of the articles seems to be on them) is that they don't scale in size and complexity. For large projects, you end up with visualizations like the LabView one in the article. For complex projects, you try to tame the complexity by offering a textual language to program complex components, with the consequence that you are constantly switching between the two representations.

zozbot234 4y ago
Visual programming should be one of many ways of interacting with a codebase. Some software abstractions are inherently quite conducive to a visual representation, such as anything that can be understood as a monoidal category. (Ordinary dataflow is indeed one example of this, but there are others; and even the modeling of dataflow introduces some extra subtlety, which is barely acknowledged in OP) Others, not so much; and a textual representation might both be more compact and ultimately clearer.
- 082349872349872 4y ago
  The usual algebraic textual representation is, after a fashion, also a visual representation. Compare how 'w § x § y § z' —or '(§ w x y z)' for the lisp weenies— brings together an operation and its arguments in a single visual chunk, to how in RPN there are many ways for the arguments and their operations to be arbitrarily separated in the textual stream.
- agumonkey 4y ago
  Good point. Another thing is that program gets desugared into graphs anyway..
  - mountainriver 4y ago
    Yeah but the AST is super complex and you wouldn’t want to interact with it directly

smartmic 4y ago

DSPatch[1] is a pretty usable dataflow framework for C++ enthusiasts. [1] http://flowbasedprogramming.com/docs/html/index.html http://flowbasedprogramming.com/docs/html/index.html

z9znz 4y ago

I used a visual data analytics toolkit for several years to help big telcos reconcile switch vs billing data. The tool was very dated looking, but it was ideal for the specific tasks we were performing. I found the best use was as a discovery tool. Often a business would believe it knew its own processes and rules, but with large complex systems (often quite old software, especially on the billing side), it was very difficult for the companies to know if what they believed were the business rules were actually what was happening in their software. So we would work with the client to visually express these rules, in steps and phases, using visual flow-based development. It was kind of similar to REPL-based programming in that you could drop a node on the canvas, hook it up to a previous output, and run it immediately. Then you could inspect the outputs to see the result. Of course there were also UI features which made it very easy to get various details at a glance, such as number of elements on outputs with additional details on hover (min/max, avg, etc.) Being visual, it was also easier for non-technical clients to grasp what was going on. It was sort of a bridge language which allowed us to communicate with the client. Often the client would come up to speed with this representation and actually get involved in the building process. Eventually you have accurately modeled the business process, or at least what the process _should_ be. Then if the numbers coming out aren't right, you do additional analysis to identify the root causes. Then you build some following models which compensate for this to ensure the correct output. Finally, you have a formula of sorts which can then be implemented in other more production/repeatable code. On average, a client would recover $10 in lost revenue (due to billing errors) for every $1 they spent on our time. An unexpected side benefit of this process was that new observations could be made which might shape future business decisions. This was especially useful for new business models (such as design and implementation of early in-flight wifi services). Regarding model/diagram complexity, that was solved in the same way we solve complexity in text-based coding. You just organize details into sub-models, drilling down or stepping out to different views. One complex model might end up with a single node representation within a higher level model. I always wished we could have UI views like this on normal software projects to help in those times where your head gets lots in the complexity of dozens of modules and hundreds or thousands of functions (seeing the forest despite the trees, etc.)

chaosprint 4y ago

Very interesting topic for me. Thanks for posting this. As pointed out in other post, it's widely used in audio/music programming. My project Glicol(graph oriented live coding language) joins this list recently: https://glicol.org https://glicol.org I managed to use solely text based style for denoting audio graph. But often I am asked why I have no visual programming interface for it. I would be happy to listen to all the feedback from you at the repo: https://github.com/chaosprint/glicol https://github.com/chaosprint/glicol

FractalHQ 4y ago
Seems to be silent on iOS. Any idea why? Looking forward to checking this out at my computer later!
- chaosprint 4y ago
  Which browser are you using? If I remember correctly, the audio on iOS devices requires iOS >= 14.5
yboris 4y ago
Mindblowing! Thank you for creating this (and for sharing the link!) The demo page is stellar: https://glicol.org/demo#ambienthouse https://glicol.org/demo#ambienthouse

soco 4y ago

The flow programming is for me at home in integrations. Middleware like Apache Camel, data pipelines like Jaspersoft or workflows like Activiti always offered an IDE with graphical representations of those flows - traditionally a bit kludgy maybe. The newer Ballerina cloud integration language from WSO2 offer this duality code-visual natively.

jcelerier 4y ago

A small issue with flow-based programming is that it often doesn't have a good way to represent time and sequencing over "human" time scales - the main project I work on, https://ossia.io https://ossia.io combines timeline and dataflow to solve this. It's mainly used by artists but I always wonder about the other potential use cases for it... if anyone has ideas :D

di4na 4y ago
Runbooks or any kind of ops agent would probably fit well. In particular something like a start/stop/init daemon At least in my mind. Hell even a deployment tool would probably fit some of that paradigm. It would ofc need some work to adapt it and maybe something like Crochet would make more sense but eh

DavidPP 4y ago

Node-RED is also fairly popular in home automation circles, but it's a generic tool that can be used for different purposes. For example, it can also be used to build chatbots. https://nodered.org/ https://nodered.org/

riekus 4y ago
Nodered is really awesome. I work in the Salesforce ecosystem where flow based programming is being pushed and adopted and always wish they would have adopted the nodered way of doing things.
monkeydust 4y ago
+1 suprised it wasnt mentioned. Use it heavily in home assistant to connect up devices that were never designed to talk to each other to do some interesting things.

abrax3141 4y ago

Seems like the analysis is missing functional programming, which is basically flow based.

jeffreygoesto 4y ago
Why is this comment being downvoted? The nodes of a flow graph (usually) are equivalent to pure functions. The graph represents chaining of those functions and the ports of the nodes are their type signatures. There is a comment in parallel that correctly states "getting down" is a gap or difficult. This maps to the fact that functional programming paradigms are easier to use higher up and deep down it somehow gets imperative on the way, and be it only in the compiler...