A visual representation of objects in a programming language context must necessarily be complete descriptions of those objects; either you're switching rapidly between multiple levels of abstraction in order to perform your work, or the sheer volume of screenspace necessary to encapsulate even relatively simple programming instructions results in difficulty comprehending program flow as a singular process.

Or, to put it another way - open up a simple paint program, and try drawing out a visual-programming approach to a very simple programming problem - say, reading the first twenty entries from a database and selecting a tuple based on the highest-valued column. Make the fake program logically complete; it should encapsulate every operation and data structure necessary (although you can presuppose libraries to interact with, it should represent those libraries, as well).

This is actually a problem I've been working on on-and-off for my company; we're trying to implement a comprehensive visual editor for our program, instead of the multiple-layers-of-abstraction visual editor that exists today. As it transpires, given the vast amount of information that needs to be available, symbol encoding - memorizing the meanings of large numbers of symbols in the context of the UI - is the only effective means we've found. And at that point you're just writing a scripting language using different letters than the English ones, and what's the point?