One of the problems with text-based programming is that it scales rather too well. I've had to deal with C functions which were 1000 lines long. You simply can't abuse a visual language like that. As you approach the Deutsch Limit, the complexity of what you've drawn becomes immediately apparent and you have to think about ways of reducing it, by structuring your code better, e.g. splitting up complex functions into two or more simpler ones.
I can assure you that there's an analogous person who can do the 1000 lines drawing (or whatever the equivalent monstrosity is). And if that is impossible, it means the language is too limited to be of real use.
We've had many programming paradigms over the years, most delivered and we can argue about their merits. To the best of my knowledge the only somewhat successful visual programming systems are simulink and lab view, which are extremely limited, and any nontrivial use does venture into the "dreaded" textual.
I would love to be proven wrong, but I suspect it is inherent. A picture might be worth a thousand words, but movie scripts are still written as text, and graphic novels are a minuscule part of the market.
In my opinion It is similar to the misguided notion that some people have that if only math notation (or physics notation, or music notation, etc) was more graphic/elaborate/readable, it would be easier and accessible. This is wrong: the notation is just the top of the iceberg you see above the water. The underlying complexity is the real issue, and it won't go away with a different notation.
Movie scripts and novels, graphic or otherwise, contain a narrative which is inherently sequential, and the best way to capture that is in text.
Programs in general are non-sequential (MIMD). They are normally expressed sequentially because early hardware was inherently sequential.
Music notation is graphical. So are Feynman diagrams, circuit diagrams, maps, blueprints, structural formulae, etc. Not everything is best expressed as text.
Other successful visual dataflow systems include Max, Reaktor, and Flow-based programming. The field is in its infancy and we can't be sure yet what works and what doesn't.
Most of computing is actually sequential, or a small set of sequential computations carried in parallel, often reactively based on an input. So you agree that in cases well described this way (e.g., a Word processor or a Web browser or an Excel spreadsheet) text is a better decription of the computation? Specifically, re:excel, I'm talking about describing Excel itself, not a specific spreadsheet (which may sometimes have a reasonable graphical representation)
Music notation is graphical, and still gets complaints for being "hard to read" by people who haven't mastered it. My intention for bringing it up was not "see, it's not working", but rather "see, it doesn't make things simpler".
Circuit diagrams are graphical only for very small and simple circuits, which illustrates my point about scaling - there is no circuit diagram for any circuit with more than a few tens of elements anymore. Take a simple processor, for example - there are textual descriptions (verilog, vhdl, ihdl, ...) which are compiled into logic gates and/or netlists (textual or binary), and the result of layout (which is graphical, but not for human consumption). There's a block diagram, yes, and a small number of those blocks can be zoomed into another block diagram or a circuit -- but by and large, with the exception of manual layout tweaking, it is textual -- and that's in an area that started with diagrams and still champions them in its courses.
I disagree that the field is in its infancy - we've had pen and paper diagrams for everything in computing since forever, none of which has scaled so far to a complete system (some are ok for toplevel, some are ok at the really bottom level, non work in the middle) , including flow charts, data flow diagrams, UML and its tens of different diagrams, etc.
I would love to be proven wrong, though, but personally I have given up on this kind of things.
