> If you try to make a visual language as flexible as a general purpose programming language Visual languages don't need to fully replace a general purpose lan

> If you try to make a visual language as flexible as a general purpose programming language Visual languages don'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. 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'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. 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. 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 "organically" 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. I have hope that some breakthrough in visual programming is still possible by creating programming languages that don'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. [1] https://en.wikipedia.org/wiki/Programming_by_example https://en.wikipedia.org/wiki/Programming_by_example [2] http://aprt.us/ http://aprt.us/