&gt; If you try to make a visual language as flexible as a general purpose programming language<p>Visual languages don&#x27;t need to fully replace a general purpose language to be useful; a good combination is where you use text to represent the abstractions in your program, and visual tools to represent the values.<p>You can see this at work in one of the most successful visual tools, the interactive debugger, now embedded in every IDE worth its salt. The program&#x27;s architecture is written in pure text, but the execution traces can be filtered, watched and poked interactively, rather than the textual alternative of writing everything to a giant linear log file.<p>Visual environments are best at the initial exploratory phase of software design, when requirements are not fully specified and the code structure is still fluid.<p>What all visual languages so far are missing is a way to build (textual) abstractions from the initial concrete, visual design. This would allow the programmer to grow the program &quot;organically&quot; by working with the data, without the need to write down every abstraction from scratch in text. There are Programming By Example[1] techniques that could help with this, but they are not well known nor widespread.<p>I have hope that some breakthrough in visual programming is still possible by creating programming languages that don&#x27;t try to copy imperative programming, but instead exploiting the strengths of a visual environment. Tools like Apparatus[2] show that this approach is a viable one.<p>[1] <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Programming_by_example" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Programming_by_example</a><p>[2] <a href="http:&#x2F;&#x2F;aprt.us&#x2F;" rel="nofollow">http:&#x2F;&#x2F;aprt.us&#x2F;</a>