The way I see it is that we've had an evolution of how to program computers. It's been:
circuits -> holes in cards -> text -> <plateau with mild "visual" improvements to IDEs> -> __the future__
I think many programmers are just unable to see the forest through the trees and weeds, but visual languages see a lot of power in specific domains like art, architecture, circuit and FPGA design, modeling tools, and control systems. I think this says something and also overlaps with what the Racket folks call Language Oriented Programming, which says that programming languages should adapt to the domain they are meant to solve problems in. Now all these visual languages are separate things, but they are a portion of the argument in that domain-specific problems require domain-specific solutions.
So what I believe we'll have in the future are hybrid approaches, of which LabVIEW is one flavor. Take what we all see at the end of whiteboard sessions. We see diagrams composed of text and icons that represent a broad swath of conceptual meaning. There is no reason why we can't work in the same way with programming languages and computer. We need more layers of abstraction in our environments, but it will take work and people looking to break out of the text=code thing. Many see text as the final form, but like I said above, I see it as part of the evolution of abstraction and tools. Text editors and IDEs are not gifted by the universe and are not inherent to programming; they were built.
This has already happened before with things like machine code and assembly. These languages do not offer the programmer enough tools to think more like a human, so the human must cater to the languages and deal with lower-level thought. I view most text-based programming languages similarly. There's just too many details I have to worry about that are not applicable to my problem and don't allow me to solve the problem in the way that I want. Languages that do provide this (like Elixir, F#, and Racket) are a joy to use, but they begin to push you to a visual paradigm. Look at Elixir, most of the time the first thing you see in an Elixir design is the process and supervision tree. And people rave about the pipe operator in these languages. Meanwhile, in LabVIEW, I have pipes, plural, all going on at the same time. It was kind of funny as I moved into text-based languages (I started in LabVIEW) to see the pipe operator introduced as a new, cool thing.
In general, I have many, many complaints about LabVIEW, but they do not overlap with the complaints of people unfamiliar with visual programming languages, because I've actually built large systems with it. Many times, when I go to other languages, especially something like Python, I feel I've gone back in time to something more primitive.
Text-based representations have tremendous upsides (granularity, easy to input, work with existing tools, easy to parse), but they also have downsides I think people tend to overlook. For example, reading and understanding code, especially foreign code, is quite difficult and involved; involves a lot of concentration, back and forth with API documentation, searching for and following external library calls ad nauseum. Comments help, but only so much. Code is just difficult to read and is expensive in terms of time and attention.
> Text editors and IDEs are not gifted by the universe and are not inherent to programming; they were built.
Bret Victor has some good presentations that addresses this idea. One thing he says is that in the early stages of personal computing, multitudes of ideas flowered that may seem strange to us today. A lot of that was because we were still exploring what computing actually was.
I don't dislike programming in vim/emacs/ides. Is it good enough? Yes, but... is this the final form? I think it'll take a creative mind to create a general-purpose representation to supersede text-based representations. I'm excited. I don't really know of anyone working on this, but I also can't see it not happening.