(This is essentially a re-phrasing and re-ellaboration of this answer in StackExchange::SoftwareEngineering)
The answer to this all-time question is not actually complicated, but it is rare to find the real reasons for it since they require a lot of experience and insight in programming. Intuitively, the fomer does seem better than the latter, because, after all, visual things are more pleasant to the eye!
In my opinion, the best and more truthful explanation of why visual programming languages are not better than textual ones for practical coding (except in particular scenarios, see below) goes like this:
- The end goal of visual programming is to make programming simpler, more manageable than textual code writing.
- The only way of making something simpler is to drop unnecessary details (complexities) in the code.
- Unfortunately, in any kind of programming, those details are as a necessary part of the code as any other; morevover, usually they are the ones that are more difficult to represent graphically or more likely to not produce any gain by being represented that way (e.g., assigning values to variables or writing expressions).
- If those details are abstracted away, the program gets incomplete and cannot run; if those details are reintroduced in visual form, the program gets cluttered and difficult to understand, definitely not easier than text programming.
Besides, we cannot ignore the fact that textual programming is visual: a text is arranged on a plane just as visual programs do, and many of its structures have geometrical layouts enforced by indentation, syntax highlighting and segment folding (provided by the code editor), names formatting, visual signs like comment marks, etc. How much more visual can it get without losing completeness —while reducing complexity?
Halt there! I am not saying that visual programming languages are useless! Actually, there exist a lot of them out there for a diversity of purposes… For instance, they are good for designing (abstract) programs, or for specifying some of their underlying or implicit structures, or for coding in very particular dominions.
What I say is that when it comes to write a complete computer program that can be run on its own, they almost always must be complemented with certain textual coding, and, therefore, if a suitable (and delicate) balance is not achieved, the effort of that, plus the effort of maintaining correctly synchronized a software that exists at the same time in two different ontologies (visual / textual), are simply not worthy.
