Now that I Google it a bit, it seems you're right that my definition of "visual programming" is too strict, although I do still think that most people wouldn't consider Python's whitespace to qualify. It looks like most so-called visual programming environments are effectively visual diagrams of standard control flow mechanisms like loops and conditionals.

The point I was trying to make is that the text in a programming language like Python is like a visual diagram of standard control flow mechanisms. I can see the for loop, what it iterates, and what the body of the iterator is. The language has visual clues. And with syntax highlighting it's even more visual.

But, I get that there is a class of visual languages, often dealing more with interconnected nodes like a directed graph, for which graphics might be better at communicating. But they seem more domain-specific rather than general purpose programming (like most text languages).

I think the "visually representative of the output" isn't a suitable way to describe it.

The visual language I always think of is LabVIEW. It is very different than a textual language.

No it's not. A for loop is a block with inputs, a space for sub-blocks, and outputs. To add an iteration limit, a box with a literal number can be attached. This is visually represented of the program's flow graph. Which does make sense when actual signals are concerned, to extend the wire metaphor of analogue equipment. Reason did that too, where instruments had a back pane to connect them to effect panels via actually visualized wire plug-in. Buzz or unreal blueed apply the same idea, as does model-sim. Block diagrams are just a very popular abstraction in signal theoretic topics. So Algol syntax, the languages like C being close to the hardware, uses the same visual metaphor.

Erlang (Prolog) for example doesn't so much. Sure you have parameters, but matching blocks aren't strictly evaluated in sequence.

> This is visually represented of the program's flow graph

LabView is more of a data flow graph than a control flow graph, aside from the boxes that represent deviations from the usual rules (For loops, conditionals, sequences, etc.)

This isn't as much pedantry as it might seem... this is one of the big differences between LV and 'traditional' programming... LabView evaluates its data flow graphs in data-dependency order, which can also mean evaluations are done in parallel. (IIRC, for linear execution speed, wires in LV all have a fixed type and blocks can be compiled to machine code with an LLVM back end.)