Visual programming is not going to solve this unless the visualisation matches their domain-specific notation instead of a visual graph that has separate edges for "then" and "else". At that point, why bother with the visual notation instead of just putting it in text they understand equally well?

You make a fair point.

> why bother with the visual notation instead of just putting it in text they understand equally well?

Consistency of implementation - even across different domains.

Learning/Thinking - different people learn and think in different ways (Visual Learning - https://en.wikipedia.org/wiki/Visual_learning, Auditory Learning - https://en.wikipedia.org/wiki/Auditory_learning, Kinesthetic Learning - https://en.wikipedia.org/wiki/Kinesthetic_learning)

Ease of Use - It is not possible to have syntax errors. (Logical errors/misunderstandings of the problem being solved are still possible).

I'm not quite sure what "text they understand" means. Are you talking about natural language interpreters (as you mention above)? That would/will be some cool technology and my feeling is that it is a "next step" in software evolution. Maybe, more likely, the next step is a planned or constructed language interpreter (http://en.wikipedia.org/wiki/Constructed_language). Natural language is so tricky (but maybe not for very domain specific problems).

I mean text that approaches natural language if not natural language. I think something like Inform 7 is far more likely to be adopted by that audience than a visual graph that is just an abstraction of loops and functions. I think the benefits of a textual language matching a domain are much greater than a general-purpose visual programming language.

If it targets, say, a visual learner, I think a graph language won't help unless they are already visualising the program as a graph.