I used LabView in college and a couple of other visual programming schemes in my work that have since disappeared, and they all had the same drawbacks: If your needs fit tidily within the assumptions made by the designer, they can be very productive indeed. Once you step a little bit outside of that, they turn into a tortuous mess. Can't even count the number of times I wished I could just write a few lines of code instead of trying to figure out a byzantine way to hook up enough icons that I got my desired end result.
I've always been told by labview advocates that "you can of course pull up a text editor and write code." The language and API is certainly a different matter, being a second class citizen and presumably an afterthought.
There's a bit of a stereotype about labview that it is graphically beautiful but its not visual programming because it inevitably results in more typing of text than anything else, otherwise you get a bowl of spaghetti. With textual languages you can interpret it to figure it out, perhaps a billion times slower than the computer, but exactly the same. Visual is a little harder to figure out.
Or in summary I've seen large complicated Labview that's totally write once read never.
You might be interested in screenshots from GNURadio. Same effect. Spaghetti bowl of a schematic where a plain text version would be a lot clearer. Google for a simple WBFM radio with squelch and AFC aka your $5 walkman broadcast radio, and you get something that looks like its launching the space shuttle.
I never personally used LabView (well, maybe in a Physics 101 lab in college, but that was a while back). The people using it in the offices I've worked in have generally been electrical engineers, perhaps the schematic view meshes better with their mental model of computation. It seemed to work well on most of the projects.
EDIT: I should add, when I did look at the LabView stuffs, it seemed to make sense to me (as a reader), but I'm not sure how easy or difficult it would have been for me to jump into and start working on after someone else has constructed a lot of parts.
I suspect that of equal importance to the schematic view, for electrical engineers, is the dataflow programming model. Another dataflow based programming tool, albeit non Turing complete, is Excel.
I have thought of excel as the closest real thing we have to visual programming.
Its a shame that it seems to be based on a "grid" rather than a better data structure. I guess that is why it makes sense to most non programers though.
LabVIEW and the rest of visual/graphical programming needs to perfect the feature for cleaning the code layout. LabVIEW does a good job about half the time, but the other half results in time wasted to make the code legible. Mathematical formulas look nasty, which results in having to use a "Formula Node"[1]. The other major problem with LabVIEW is the speed at which you program is not much faster after you understand the fastest ways to do things, because you are still limited to how fast you can click and connect nodes.
Did I say it was the pinnacle? GGP post suggested that visual programming was vaporware. Perhaps for general purpose programming it is, but visual programming itself is not vaporware.
Visual programming has small niches where it fits well. GUI building for example. Actually the query builder in MS Access wasn't so bad, but it was a choice of learning that or remembering "proper" SQL when I used it. Proper SQL seemed more useful.
Likewise with functional programming. I uses small bits here and there when it is appropriate to write cleaner code. I would struggle to build anything of any size using FP.
I believe that's an example of visual/graphical programming, it's fairly mainstream in some areas and not vaporware.
Re: Rest of comment - Filtered site, I'll read it at home.