The basic idea is that most user interfaces get in the way by intervening between the users and the actual system objects, enforcing process oriented interactions and introducing UI - object synchronization problems. Giving the user the ability to interact directly with the objects and enforcing a 1:1 relationship between what the user sees on the screen and the objects used to represent them allows the users to become problem solvers rather than process followers.
We see code on the left and a result on the right, but it's the steps in between which matter most. The computer traces a path through the code, looping around loops and calling into functions, updating variables and incrementally building up the output. We see none of this.
Traditional visual environments visualize the code. They visualize static structure. But that's not what we need to understand. We need to understand what the code is doing.
Visualize data, not code. Dynamic behavior, not static structure.
— Learnable Programming - Bret Victor
"Visual Programming" failed (and continues to fail) simply because it is a lie (...)
When I write code, for example a layout algorithm for a set of GUI elements, I visually see the data in my head (the GUI elements), then I run the algorithm and see the elements "move" into position dependent upon their dock/anchor/margin properties (also taking into account previously docked elements positions, parent element resize delta, etc). This is the visual I need to see on screen! I need to see my real data being manipulated by my algorithms and moving from A to B. I expect with this kind of animation I could easily see when things go wrong naturally, seeing as visual processing happens with no conscious effort.
Instead visual programming thinks I want to see the textual properties of my objects in memory in fancy coloured boxes, which is not the case at all.