Visual programming works very well when you have data flowing, but it doesnt work when you have loops and branching. But it is nice to support graphs for some tasks, it really speeds up some processes.
>but it doesnt work when you have loops and branching
We managed to make visual programming work well with loops [1] and more or less OK with branching [2]. The trick is to look at loops from a functional perspective (i.e. as iter/map), rather than from imperative.
I think the ultimate test is whether it can be self hosted. eg. can the program be used to create the program itself!? Or what problem does it solve?!?
Both loops and branching/dispatching are examples of control flow, which is essentially independent from the 'data flow' default of most "visual programming" approaches. You can actually show both in the same visualization, but only in a well-defined "sub-diagram" sense. That is, a "block" in a data-flow visualization can be defined by a flowchart (showing control flow), and vice versa.
The dual problem is that flowcharts (in the traditional, control-flow-only sense) cannot show fork-join parallelism or fixed point constructions, while both are readily expressible by data flow.
I like PraxisLive[1] because it combines both code and nodes. Reconnecting nodes in different ways it's ideal for experimenting with different implementations or trying out different orders when applying filters (which works both for audio and graphics effects). It also facilitates changing values in real time without stopping the program, which is perfect when developing time-based software.
I also think visual coding works for high level abstractions rather than low-level procedural style workflows. E.g. for ML a visual flow could be import some data, train a model, deploy model to cloud. Orange Data Mining is an example of visual programming at the right level of abstraction but stops short of including enough modules to be useful in common data science workflows:
dgudkov|6 years ago
We managed to make visual programming work well with loops [1] and more or less OK with branching [2]. The trick is to look at loops from a functional perspective (i.e. as iter/map), rather than from imperative.
[1] https://easymorph.com/learn/iterations.html
[2] https://easymorph.com/learn/conditional-workflows.html
z3t4|6 years ago
zozbot234|6 years ago
The dual problem is that flowcharts (in the traditional, control-flow-only sense) cannot show fork-join parallelism or fixed point constructions, while both are readily expressible by data flow.
hamoid|6 years ago
[1] https://praxislive.org/
brylie|6 years ago
https://orange.biolab.si/