Developers who've significant experience with functional programming understand that it would be easier and more reliable to solve many (or most) problems using a functional language over an imperative one. But the majority of developers have little to no experience with functional programming. In almost every conceivable way widespread adoption of functional programming would make everyones jobs significantly better. And these days we are beginning to see mainstream imperative languages starting to incorporate functional concepts slowly because people are starting to realize the value of it.
Right now we have far superior tools available to us than the ones used by the average programmer, but due to a combination of historical reasons, poor education, and sheer inertia of past commitment to inferior tools, we don't yet see widespread adoption of the superior tools that are already available.
The visual languages that I've seen so far are a kind of adaptation of existing languages to make them simpler and more accessible to beginners. What I'm talking about is not merely simplification of existing languages, but more a shift to an entirely different kind of paradigm. A shift that would require the development of new abstractions that are uniquely suited for visual programming that are not just adaptations of existing abstractions.
But as with all tools there are limitations. Certainly visual languages will not be best tool for all jobs, but there are certain classes of problems that are going to be easier to tackle with a visual language. There is also the possibility of solving a particular problem (or different parts of the problem) with both visual and text-based programming concurrently. First class support for data structures like graphs are easier to do with a visual language. I use Neo4j for graphs and the cypher query language is quite good, but it's effectiveness comes from the fact that it incorporates visual elements within the text. Something like MATCH (n)-[:REL]->(y) is a query for matching a part of the graph but you're still limited by the one dimensional structure of the language. You could imagine a visual query language for graphs being vastly more powerful in ways that a text based language couldn't possibly be.
Right now we have far superior tools available to us than the ones used by the average programmer, but due to a combination of historical reasons, poor education, and sheer inertia of past commitment to inferior tools, we don't yet see widespread adoption of the superior tools that are already available.
The visual languages that I've seen so far are a kind of adaptation of existing languages to make them simpler and more accessible to beginners. What I'm talking about is not merely simplification of existing languages, but more a shift to an entirely different kind of paradigm. A shift that would require the development of new abstractions that are uniquely suited for visual programming that are not just adaptations of existing abstractions.
But as with all tools there are limitations. Certainly visual languages will not be best tool for all jobs, but there are certain classes of problems that are going to be easier to tackle with a visual language. There is also the possibility of solving a particular problem (or different parts of the problem) with both visual and text-based programming concurrently. First class support for data structures like graphs are easier to do with a visual language. I use Neo4j for graphs and the cypher query language is quite good, but it's effectiveness comes from the fact that it incorporates visual elements within the text. Something like MATCH (n)-[:REL]->(y) is a query for matching a part of the graph but you're still limited by the one dimensional structure of the language. You could imagine a visual query language for graphs being vastly more powerful in ways that a text based language couldn't possibly be.