Lots of outfits have done drag-and-drop programming systems.
National Instruments "Labview" is probably the best-known, and the best.
The fundamental problem they all encounter is that there is no known way to convert a Flying Code Monkey into an expert programmer and engineer. As ONE example, there is no difference to a Flying Code Monkey between an O(N^2) or O(N^3) process and an O(N log N) process, which means that they must be supplied with canned routines for the O(N log N) algorithms, that can be custom-fit into the quickie graphic kludges they will build.
The second problem they all encounter is that, when you supply the special-purpose blocks required by the first problem, overhead imposed by moving the data between the blocks starts to get expensive. I worked with one very nice such system called Rippen. When I profiled, to see where we were hurting on a HIGH!-required-performance sensor processing application, I was rather disturbed to see that some 20% of my CPU time was going to data-moving. (Since I was doing LADAR image processing, doing a fair chunk of floating-point processing on every pixel of an input image, 20% of CPU was a LOT of data-moving overhead.)
You could probably get around part 2 by going to a compiler-based system: you feed it your picture, and it compiles to a heavily-optimized executable program, but I'm not certain that would really fix the issues, and it might hurt the interactive nature of the tool.