>If you think of a programming language as a set of tokens and production rules (a grammar), then can't every programming language have infinitely-many visual representations, including "pure text," "blocks/pipes" and "Jacob's Representation"?
Yes. But that doesn't say much.
Visual programming languages don't just naively show some token graph. You can get that with a parser and a graph library for any language with half a day's work.
It's about the interaction models they explore, the levels of abstraction, and the tools they offer.
What you say is like getting rid of the notion of writing, since everything that can be spoken can be also written.
>Does it make sense to call a programming language "visual"?
It very much does. For a visual language it's syntax was designed as a set of drawn objects to be manipulated. That probably also influence its very semantics.
Quartz Composer: A Visual Language.
C: Not so much.
>What if I represent a C program by a sequence of smells... The translator device reads the text from start to end, converts it to a token sequence, and emits a different smell for each token. Does that mean C is a "smell-based programming language"?
No, it just means that it also has a smell-based representation (that is impractical and noone uses). On the other hand, visual programming languages were pragmatically designed to work in a visual environment, and enable coding by the manipulation of graphical elements.
>Can't we dispense with the notion of a "visual programming language"? There are programming languages, and for each language, there are many ways to represent its programs.
A visual programming language is not about a mere representation. It's about the core way the syntax is expressed to the programmer.
What you say is like "there are no declarative, logical or functional programming languages because everything is imperative at the assembly level anyway".
Well, the level at abstraction at which the programmer is supposed to work with a language (the language's syntax) is important, even if the code can be represented in a different way. Interfaces (in the UI sense) are important.
"What you say is like getting rid of the notion of writing, since everything that can be spoken can be also written."
I think this analogy works better for the original argument, as pretty much any sentence can be either written or spoken. There's nothing about English restricting it to be only a written or only a spoken language.
Yes. But that doesn't say much.
Visual programming languages don't just naively show some token graph. You can get that with a parser and a graph library for any language with half a day's work.
It's about the interaction models they explore, the levels of abstraction, and the tools they offer.
What you say is like getting rid of the notion of writing, since everything that can be spoken can be also written.
>Does it make sense to call a programming language "visual"?
It very much does. For a visual language it's syntax was designed as a set of drawn objects to be manipulated. That probably also influence its very semantics.
Quartz Composer: A Visual Language.
C: Not so much.
>What if I represent a C program by a sequence of smells... The translator device reads the text from start to end, converts it to a token sequence, and emits a different smell for each token. Does that mean C is a "smell-based programming language"?
No, it just means that it also has a smell-based representation (that is impractical and noone uses). On the other hand, visual programming languages were pragmatically designed to work in a visual environment, and enable coding by the manipulation of graphical elements.
>Can't we dispense with the notion of a "visual programming language"? There are programming languages, and for each language, there are many ways to represent its programs.
A visual programming language is not about a mere representation. It's about the core way the syntax is expressed to the programmer.
What you say is like "there are no declarative, logical or functional programming languages because everything is imperative at the assembly level anyway".
Well, the level at abstraction at which the programmer is supposed to work with a language (the language's syntax) is important, even if the code can be represented in a different way. Interfaces (in the UI sense) are important.