3 ms·

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 an

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
    - agumonkey 4y ago
      Are they ? I enjoyed playing with lisp and even python ast.
      - mountainriver 4y ago
        I play with the python AST all the time, I love it, but its way more complex than typical flow programming
        agumonkey 4y ago
        Somehow it tickles my brain way deeper so i guess I enjoy it more even if less easy.
agumonkey 4y ago
houdini (3d animation package) can go pretty far with parametric flow based scene descriptions. I really wonder what's the actual scalability problem in other fields.
- treis 4y ago
  I used a flow based programming language for 7 years. Scale is not the issue since the nodes can be subflows. So you don't build one gigantic spaghetti bowl of a flow. You build a high level flow with the nodes being subflows. You do that recursively until actually implementing the business logic. I found it to be fantastic for building flows for complex processes. If I asked you to communicate something like a mortgage application process you're probably going to draw me a flow. So it's very natural to program in something that looks like a flow. The problem is that when you get to the task level it's not really a flow any more. If I asked you to communicate how to make pancakes you'd give me something like a recipe. Programming is similar. When it comes to the nitty gritty of building some algorithm it's easier to do it in text based code. The problem with flow based programming comes down to that gap. It's hard to bridge from the flow to the algorithm in a way that that is intuitive and with good tooling.
bmitc 4y ago
> 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. That is not true. (1) No one programs LabVIEW like that, and if they do, then they aren't doing code reviews or taking software development seriously. In fact, the visual 2D nature of LabVIEW is a feature, because it becomes immediately and visually apparent if your code is actual spaghetti or not, as in the meme-like picture that gets posted constantly. Spaghetti code certainly exists in text-based languages, but it is not so readily apparent. (2) I have built large, complex systems with LabVIEW, in fact larger than any text-based program I've worked on in industry. I wish they were publicly available/publishable to show, but they are not, unfortunately. LabVIEW scales well for the same reason that languages like Erlang and Elixir scale well. It has built-in concurrency and multi-threading and the core data types, including its OOP objects, are immutable. When scaling, the issues one comes across do not relate to the visual representation but rather other issues specific to the implementation of the LabVIEW IDE.
- IshKebab 4y ago
  > No one programs LabVIEW like that. You mean it's possible to not program LabVIEW like that. Probably true but in my experience people do make programs like that (though not as extreme). I think that meme is a real program. In fairness to visual programming I think LabVIEW does give it an unnecessarily bad name purely because it is so damn ugly and unreadable. They didn't have to make everything out of Windows 3.1 16x16px icons and the ugliest line styles you could come up with. Simulink looks way nicer for example. But I still think they make little sense. Editing them is a huge pain, and adding comments is enough of a pain that nobody does it (I'm generalising; I'm sure you are the rare exception). I think it's pretty telling that logic designers use SystemVerilog and not some graphical circuit diagram type thing even though they're literally designing circuits.
  - docfort 4y ago
    I take your meaning, but just to nitpick one thing here in your argument: SystemVerilog is commonly used to model an abstract machine which is then synthesized into realizable circuits. Its selling point was compatibility and similarity to C, Verilog, and VHDL, all textual languages because the proprietary processing code was built that way. It doesn’t necessarily have to be this way, but it turned out this way, so logic designers don’t have another realistic option. Combine this with the misconception that HDLs are programming instead of modeling, and you have a setup for confusion. https://research.ibm.com/haifa/Workshops/verification2004/papers/system_verilog_overview-ibm-symposium-johny_srouji.pdf https://research.ibm.com/haifa/Workshops/verification2004/pa...

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
  - agumonkey 4y ago
    Are they ? I enjoyed playing with lisp and even python ast.
    - mountainriver 4y ago
      I play with the python AST all the time, I love it, but its way more complex than typical flow programming
      - agumonkey 4y ago
        Somehow it tickles my brain way deeper so i guess I enjoy it more even if less easy.

agumonkey 4y ago

houdini (3d animation package) can go pretty far with parametric flow based scene descriptions. I really wonder what's the actual scalability problem in other fields.

treis 4y ago
I used a flow based programming language for 7 years. Scale is not the issue since the nodes can be subflows. So you don't build one gigantic spaghetti bowl of a flow. You build a high level flow with the nodes being subflows. You do that recursively until actually implementing the business logic. I found it to be fantastic for building flows for complex processes. If I asked you to communicate something like a mortgage application process you're probably going to draw me a flow. So it's very natural to program in something that looks like a flow. The problem is that when you get to the task level it's not really a flow any more. If I asked you to communicate how to make pancakes you'd give me something like a recipe. Programming is similar. When it comes to the nitty gritty of building some algorithm it's easier to do it in text based code. The problem with flow based programming comes down to that gap. It's hard to bridge from the flow to the algorithm in a way that that is intuitive and with good tooling.

bmitc 4y ago

> 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. That is not true. (1) No one programs LabVIEW like that, and if they do, then they aren't doing code reviews or taking software development seriously. In fact, the visual 2D nature of LabVIEW is a feature, because it becomes immediately and visually apparent if your code is actual spaghetti or not, as in the meme-like picture that gets posted constantly. Spaghetti code certainly exists in text-based languages, but it is not so readily apparent. (2) I have built large, complex systems with LabVIEW, in fact larger than any text-based program I've worked on in industry. I wish they were publicly available/publishable to show, but they are not, unfortunately. LabVIEW scales well for the same reason that languages like Erlang and Elixir scale well. It has built-in concurrency and multi-threading and the core data types, including its OOP objects, are immutable. When scaling, the issues one comes across do not relate to the visual representation but rather other issues specific to the implementation of the LabVIEW IDE.

IshKebab 4y ago
> No one programs LabVIEW like that. You mean it's possible to not program LabVIEW like that. Probably true but in my experience people do make programs like that (though not as extreme). I think that meme is a real program. In fairness to visual programming I think LabVIEW does give it an unnecessarily bad name purely because it is so damn ugly and unreadable. They didn't have to make everything out of Windows 3.1 16x16px icons and the ugliest line styles you could come up with. Simulink looks way nicer for example. But I still think they make little sense. Editing them is a huge pain, and adding comments is enough of a pain that nobody does it (I'm generalising; I'm sure you are the rare exception). I think it's pretty telling that logic designers use SystemVerilog and not some graphical circuit diagram type thing even though they're literally designing circuits.
- docfort 4y ago
  I take your meaning, but just to nitpick one thing here in your argument: SystemVerilog is commonly used to model an abstract machine which is then synthesized into realizable circuits. Its selling point was compatibility and similarity to C, Verilog, and VHDL, all textual languages because the proprietary processing code was built that way. It doesn’t necessarily have to be this way, but it turned out this way, so logic designers don’t have another realistic option. Combine this with the misconception that HDLs are programming instead of modeling, and you have a setup for confusion. https://research.ibm.com/haifa/Workshops/verification2004/papers/system_verilog_overview-ibm-symposium-johny_srouji.pdf https://research.ibm.com/haifa/Workshops/verification2004/pa...