The problem with every visual programming language that I've ever tried is not that it's aimed at novices and I'm afraid of being labelled that way. It's that there's a whole wealth of tools for dealing with text based programming that just can't be used with visual programming languages without a huge amount of effort (if at all). Visual programming languages don't work well with revision control; they usually don't have diffing and merging tools. They don't work well with grep.
They tend to have a fairly low information density on the screen. When looking at a simple program that all fits on a single screen, that's fine. But when working with an actually real world code base, when I don't understand exactly what it's doing, I need to be able to see as much on screen as possible at once to keep it all in context, while browsing through to figure out how all of the pieces link together. All of the empty space taken up in a visual language makes it a lot harder to get as much information on the screen at a time.
And the programs can frequently be quite hard to follow. Tracing all of the wires between different nodes, figuring out what's stacked on what.
There's a reason that despite the very obvious circuit diagrams you could represent electronics with, hardware engineers for integrated circuits don't use a visual tool for laying out their hardware, they use Verilog or VHDL, only compiling it down to the actual netlist and laying it out at the very end.
I have never seen a visual programming language that I would say could scale to anything beyond a few basic demos, which could just as easily be accomplished in a page of code.
Xilinx actually has (had?) a visual designer tool for their FPGAs in their IDE, allowing you to connect signals between blocks and do other stuff. It didn't work well and made for unmanageable designs. I've heard similar things about complex LabView programs becoming unmaintainable spaghetti code, although I don't know if that's actually true or not (never used it myself).
Comments
The problem with every visual programming language that I've ever tried is not that it's aimed at novices and I'm afraid of being labelled that way. It's that there's a whole wealth of tools for dealing with text based programming that just can't be used with visual programming languages without a huge amount of effort (if at all). Visual programming languages don't work well with revision control; they usually don't have diffing and merging tools. They don't work well with grep.
They tend to have a fairly low information density on the screen. When looking at a simple program that all fits on a single screen, that's fine. But when working with an actually real world code base, when I don't understand exactly what it's doing, I need to be able to see as much on screen as possible at once to keep it all in context, while browsing through to figure out how all of the pieces link together. All of the empty space taken up in a visual language makes it a lot harder to get as much information on the screen at a time.
And the programs can frequently be quite hard to follow. Tracing all of the wires between different nodes, figuring out what's stacked on what.
There's a reason that despite the very obvious circuit diagrams you could represent electronics with, hardware engineers for integrated circuits don't use a visual tool for laying out their hardware, they use Verilog or VHDL, only compiling it down to the actual netlist and laying it out at the very end.
I have never seen a visual programming language that I would say could scale to anything beyond a few basic demos, which could just as easily be accomplished in a page of code.
Xilinx actually has (had?) a visual designer tool for their FPGAs in their IDE, allowing you to connect signals between blocks and do other stuff. It didn't work well and made for unmanageable designs. I've heard similar things about complex LabView programs becoming unmaintainable spaghetti code, although I don't know if that's actually true or not (never used it myself).