Many years ago, I spent a fair amount of time coding in LabView. This is a graphical programming environment initially written to allow (presumably electrical) engineers to write code to drive various data acquisition and control tasks. (I'm almost entirely a software guy, so I'm not the target audience.)
The general approach LV takes is to model computation as a data flow graph. Constructions like iteration, selection, etc. are (were?) all modeled as rectangular regions within the graph where portions of a graph can be swapped out for others or run multiple times. Graphs can also be nested to provide a means of abstraction. Execution has gone through changes over the years, but it's efficient: compiled to machine code with LLVM, and there are also versions that compile LV code to run directly on FPGA's (on some of the hardware products sold by the same company). It also takes advantage of the implicit parallelism that sometimes crops up in data flow graphs.
All in all, LV is theoretically quite impressive. (And since it's been sold for I think over thirty years, commercially quite impressive too.)
As a software engineer, though, I never fully acclimated to the way it worked. If laying out textual code is a challenge, laying out a 2D graph is much worse. The same thing goes for defining sub-graphs - 'naming a function' becomes the much worse problem of 'drawing an icon', or maybe even drawing a family of icons with a common theme. (Although I think LV's been extended with a nicer icon editor to help with this.) Input is similarly a challenge... textual tasks that can be split across two hands and ten fingers become focused on a single hand/finger. (I had to rethink my input devices both during and after the time I was using LV to avoid RSI issues.) And there are also issues with source code control. LV has some stuff baked in, but there are many years of industry-wide experience managing textual representations of code and some good tools for doing it. Switching to a different representation for code means, necessarily, deviating from that base of wisdom and practice.
So, while I think it's a powerful tool (and something more engineers should be familar with) it's nothing I'd want to do my daily work in.
The general approach LV takes is to model computation as a data flow graph. Constructions like iteration, selection, etc. are (were?) all modeled as rectangular regions within the graph where portions of a graph can be swapped out for others or run multiple times. Graphs can also be nested to provide a means of abstraction. Execution has gone through changes over the years, but it's efficient: compiled to machine code with LLVM, and there are also versions that compile LV code to run directly on FPGA's (on some of the hardware products sold by the same company). It also takes advantage of the implicit parallelism that sometimes crops up in data flow graphs.
All in all, LV is theoretically quite impressive. (And since it's been sold for I think over thirty years, commercially quite impressive too.)
As a software engineer, though, I never fully acclimated to the way it worked. If laying out textual code is a challenge, laying out a 2D graph is much worse. The same thing goes for defining sub-graphs - 'naming a function' becomes the much worse problem of 'drawing an icon', or maybe even drawing a family of icons with a common theme. (Although I think LV's been extended with a nicer icon editor to help with this.) Input is similarly a challenge... textual tasks that can be split across two hands and ten fingers become focused on a single hand/finger. (I had to rethink my input devices both during and after the time I was using LV to avoid RSI issues.) And there are also issues with source code control. LV has some stuff baked in, but there are many years of industry-wide experience managing textual representations of code and some good tools for doing it. Switching to a different representation for code means, necessarily, deviating from that base of wisdom and practice.
So, while I think it's a powerful tool (and something more engineers should be familar with) it's nothing I'd want to do my daily work in.