Far from being stuck in a bubble, I actually spent a couple years developing code in a UML-driven development environment (as in, I spent my days drawing UML diagrams that automatically turned into executable code). First of all, you cannot write any nontrivial program in UML alone. It is not nearly specific enough. UML is to a working program as a table of contents is to a technical manual. And in case you think I'm extrapolating from one bad experience, I've also used LabView have seen the parallel difficulties in that language.

Now, I agree that higher levels of abstraction will be needed in the future, but I disagree that visual programming is an obviously superior abstraction. In fact, I believe that people have been earnestly barking up that tree for decades with little success for reasons unrelated to old-fashioned attitudes. There are practical and technical reasons why developing visual programming tools and ecosystems will always be more difficult than developing text-based ones.

Take merging for example. Merging two versions of a source file is many times over a solved problem (not that there aren't new developments to be made). In contrast, merging two versions of a UML diagram is very much a manual process (to the extent that it's possible at all). Now consider creating a change management tool allows you to branch and merge UML diagrams. This is orders of magnitude harder yet. These are essential and straightforward use cases that are much more complex in a visual medium. Without these basic features, visual programming will not scale well to even medium-size teams.

I can go into more detail about issues with visual programming if I still haven't made my case. And I would love to hear from people with visual programming experience that have contradicting opinions. It's always possible that I missed something.