8 ms·

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 re

by troymc 13y ago

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"? Does it make sense to call a programming language "visual"? 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"? If the tokens get read by a text-to-speech program, does that make C an "audio programming language"? What about a different visual way to represent C programs (besides the usual text way)? Maybe we replace each token with a colored block, where each token has its own color. 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.

pandler 13y ago
There are distinct differences between (1) visualizing a program (e.g. light table), (2) using a visual interface to generate the underlying (e.g. XCode Storyboard), and (3) a "language" whose primary or sole mode of "programming" is visual (e.g. LabView). > Can't we dispense with the notion of a "visual programming language"? In most cases I agree that label is a misnomer, but I think something like LabView genuinely does fall under the category of a visual programming language.
gruseom 13y ago
Your argument is really that syntax is nothing and semantics everything. I sympathize, but it's not how most people see it. As long as we accept syntax as a significant part of what defines a programming language, "visual language" is a reasonable concept. Edit: Reasonable implementations are another matter. :)
Renaud 13y ago
Except that: - most text-based programming languages have no purely graphical counterpart. - Most purely graphical programming languages have no purely textual counterpart. - a graphic language is generally meant to abstract at a higher level and by doing so it has bigger trade-offs than a lower-level textual language (that's why most graphical programming languages are specialised and those that are too broad in their applicability domain generally fail to be useful). Your suggestions kind of miss the point: it's not about the visual representation of basic tokens. If that's your goal, then of course you could represent any token and syntax with colour, sound, smells but it wouldn't solve any problem: you would still have to use the complete original syntax, and your colourful additions would not offer any improvements to basic textual representations of the code. Graphical programming attempts to solve other types of problems. Generally, they try to hide some complexity behind a particular paradigm. Some are useful to help in learning because the building blocks can look like a concrete representation of something more abstract, like having a kind of C-jaw that represents a loop. Other systems will help alleviate complexity using domain specific visual languages that would be difficult to represent textually: electronics for instance, or connection between musical equipment, or animations engines, etc. Bottom line is that yes, they are all languages but while most textual programming languages are versatile and generally allow any level of complexity, graphical programming languages are sometimes better fits when the domain is much narrower. They also generally operate at a different abstraction level.
- troymc 13y ago
  Fine, but give me a program in any programming language, be it "text-based" or "purely graphical" and it's probably possible to translate it into a representation that's vice versa. (Problems arise when a representation is too abstract: ambiguity can occur.) Program representations are like city maps. There's only one city, but there are many maps: the subway map, the map of post offices, the map of gas lines, the map of Wi-Fi coverage, and so on. I will agree that different representations have different capabilities and use cases. However, text is also capable of great abstraction, e.g. z2 = BesselJ(n, z1)
  - mbrock 13y ago
    You're kind of stretching the definition of "language," though. Programming language grammars are defined textually. Do you think, for example, that a (useful) pictorial representation of Haskell code can be derived simply from the language grammar? Sure, the map is not the territory, but you can also say the language is itself the map, and the territory is something way more abstract, like "computation." Perhaps you can take the semantics of Haskell and invent a graphical syntax for it, perhaps even strongly inspired by the textual syntax of Haskell. But it wouldn't be straightforward, and any obvious, straightforward attempt would probably be terrible. In other words, I don't think it's obvious that there is a "deep structure" of programming languages that can be worked on directly in a wide variety of formats. Unless you count the AST as such a structure, in which case graphical programming is reduced to graphical tree manipulation (which admittedly is the path taken by many of these examples).
    - nitrogen 13y ago
      Dataflow languages (like the one I developed: http://www.nitrogenlogic.com/docs/palace/ http://www.nitrogenlogic.com/docs/palace/) seem like they would have a fairly straightforward mapping to/from a purely functional language like Lisp.
      - mbrock 13y ago
        That looks cool! By the way, the more I think about this, the less I seem to know even what a "language" is. Is Lisp a language? No, it's a family of languages, but even Scheme is a language known for its minimal grammar and its infinite extensibility. A common critique says that one programmer can't understand another's Lisp code because there's such a great potential for redefinitions and domain-specific syntactic extensions. If Lisp has a slogan, it's "code is data." Is Lisp a meta-language, or even an anti-language?
ericHosick 13y ago
If you really get to thinking, programming is all about abstraction. We talk about abstract concepts like functional programming, object oriented programming, structured programming, objects, functions, methods, inheritance, etc. But, in the end, it's all just playing around with stack pointers, instructions and malloc. As Permit points out here (https://news.ycombinator.com/item?id=7274956 https://news.ycombinator.com/item?id=7274956), a large part of a programmers job is to build a "mental model of their program". We abstract things and come up with constructs to represent these abstractions to make it easier for us to program a computer: to improve on our mental model. So, we come up with different programming languages and label them by their approach. This is a functional programming language, this one is declarative, this one is procedural and this one is visual. My 2 cents.
dinkumthinkum 13y ago
No I think you're being sort of outlandishly ridiculous .... just to be honest. You would have us not allow for any sort of classification of programming languages then because they are Turing complete.
- troymc 13y ago
  It's fine to classify programming languages. It's not fine to get confused between a programming language and a way of representing a particular program. For analogy, there's only one true physical Earth, but there are many possible maps (representations) of the same area: one showing the temperature at the surface (using color), one showing wind direction at various points, one showing roads, etc. Which map is correct? Which map is best?
  - greatsuccess 13y ago
    But a programming languages goal is to make the Earth. Not to represent it.
  - dinkumthinkum 13y ago
    Your analogy doesn't really make sense. What we are doing is saying: "This is an object language, this one is functional, this one is visual." Again, your problem seems to be more one of not wanting us to call any programming language with any adjectives differentiating it from others ...
spyder 13y ago
I agree, they should be called "visual programming environment"
agumonkey 13y ago
To me it's neither of them. I don't know how I'd call that, semantic .. ontologic ? The 'text' is as much an interface to the abstract model as the 'visual'. When I see repls with sophisticated real-time output representation it's as much visual as dataflow programming by connecting nodes to an output sink. Brett Victor's work is bringing them even closer since usually dataflow/reactive was used in mathematical settings (time varying scala or scalar arrays... image or sound) but he demonstrated far more the benefits in non linear logic (games). It's the disconnected, char per char ascii, file saving, build time, run time tradition that creates an artificial segmentation.
- chevreuil 13y ago
  Relevant Bret Victor video : https://vimeo.com/66085662#t=9m20s https://vimeo.com/66085662#t=9m20s
  - agumonkey 13y ago
    Can't be clearer. ps-edit: of course he's always clearer, that's why we watch his talks.
twelvechairs 13y ago
This is exactly why most 'visual programming languages' don't take off - because they fixate on a single means of repreaentation - which will never cover all use cases (and text representations can cover the same territory just as well) rather than doing what they should do - allow varied representations of programs.
- vorg 13y ago
  Yes! All language, whether natural or programming, can have two primary structures: semantic and thematic (these are terms from Linguistics). Thematic structure (very roughly) refers to the effect of the writer, the medium, and the reader/s, which explains why one semantic structure can be represented in a variety of ways.
NAFV_P 13y ago
> 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"? If C was represented in an olfactory manner my code would be deemed a bio-hazard.
- aaronem 13y ago
  Certainly lends new meaning to the concept of "code smell".
  - NAFV_P 13y ago
    "Damn, your code stinks man!" I have never happened across this bizarre piece of jargon, but I goooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooogled it, cheers.
coldtea 13y ago
>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.
- jimbokun 13y ago
  "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.
jimbokun 13y ago
The project I work on has a custom querying DSL, and recently we have been working on a visual query builder for this language. So this is a very concrete example of a language with both a textual and visual representation. Of course, keeping fidelity between both representations can be a challenge. Our design could be improved by being more diligent in sharing the same underlying model for both. I imagine there are other cases like this, where you have a visual tool for building expressions for some textual language. (Are there SQL tools like this? Seems likely there would be.)
aufreak3 13y ago
At its core, a programming environment provides a link between a formal system and some aspect of our world. You could think of a general purpose Computer as providing a link between any formal system and the aspects of our world that it ties int, but we can limit ourselves to programming environments for simplicity of discussion. With that perspective, we can ask what representations of a formal system do we find easy to manipulate in ways that produce results that are significant for us (in a specific problem context). A visual representation would certainly be a better match for a spatial problem domain (Sutherland's work, for example). Similarly, an audio representation can work well for an audio domain (ex: beardyman's realtime performance system he presents in his ted talk). Likewise, I'm quite sure a system for exploring cuisine art would match a "smell representation". The notion of a "universal turing machine" guarantees that all of these representations can be mapped to that of a symbol stream. That is a mathematical result, but which representations appeal to humans involved in various kinds of work is not a mathematical question - it is a HCI question.
MSF2014 13y ago
(1) Look at CPWCT, a visual programming language (based on the C programming language, and developed/used inside Programming Without Coding Technology (PWCT) See this online movie to get quick idea without downloading the software : http://www.youtube.com/watch?v=461iVUl08mQ&list=PLpQiqjcu7CuHg6IRXVdt9MILiHG7JSVq7&index=24 http://www.youtube.com/watch?v=461iVUl08mQ&list=PLpQiqjcu7Cu... When you see this movie you will discover the difference between a Visual Programming Language like CPWCT and a text-based programming language like C (2) When we use a text-based programming language, think of this using ( command-line / terminal ) of the operating system instead of using the GUI to do your tasks. (3) Designing a visual programming language is an art (more complex than designing a text-based programming language) because the user interface of the visual language is more advanced. (4) Using a Visual Programming Language, we can see the visual representation text in natural language (English, French, any other language) and we can change the visual representation and we can allow the programmer to change the visual representation (not easy to allow the programmer to change the syntax of a text-based programming language, we can do this, but the programmer will need to recompile the lexical analysis program, and it will be another language that can't recognize programs that are written using the old syntax, while in visual language we can allow this customization and we still open any programs create before or after this customization). (5) We can add more dimensions to the visual programming language (like the time dimension). this dimension is not known to text-based programming language. you can move forward/backword during application construction process, and you can run programs in the past, you can see a movie of how to create the program step by step See this movie : http://www.youtube.com/watch?feature=player_embedded&v=wpxbfPxNHqg http://www.youtube.com/watch?feature=player_embedded&v=wpxbf...

by troymc 13y ago

pandler 13y ago

There are distinct differences between (1) visualizing a program (e.g. light table), (2) using a visual interface to generate the underlying (e.g. XCode Storyboard), and (3) a "language" whose primary or sole mode of "programming" is visual (e.g. LabView). > Can't we dispense with the notion of a "visual programming language"? In most cases I agree that label is a misnomer, but I think something like LabView genuinely does fall under the category of a visual programming language.

gruseom 13y ago

Your argument is really that syntax is nothing and semantics everything. I sympathize, but it's not how most people see it. As long as we accept syntax as a significant part of what defines a programming language, "visual language" is a reasonable concept. Edit: Reasonable implementations are another matter. :)

Renaud 13y ago

Except that: - most text-based programming languages have no purely graphical counterpart. - Most purely graphical programming languages have no purely textual counterpart. - a graphic language is generally meant to abstract at a higher level and by doing so it has bigger trade-offs than a lower-level textual language (that's why most graphical programming languages are specialised and those that are too broad in their applicability domain generally fail to be useful). Your suggestions kind of miss the point: it's not about the visual representation of basic tokens. If that's your goal, then of course you could represent any token and syntax with colour, sound, smells but it wouldn't solve any problem: you would still have to use the complete original syntax, and your colourful additions would not offer any improvements to basic textual representations of the code. Graphical programming attempts to solve other types of problems. Generally, they try to hide some complexity behind a particular paradigm. Some are useful to help in learning because the building blocks can look like a concrete representation of something more abstract, like having a kind of C-jaw that represents a loop. Other systems will help alleviate complexity using domain specific visual languages that would be difficult to represent textually: electronics for instance, or connection between musical equipment, or animations engines, etc. Bottom line is that yes, they are all languages but while most textual programming languages are versatile and generally allow any level of complexity, graphical programming languages are sometimes better fits when the domain is much narrower. They also generally operate at a different abstraction level.

troymc 13y ago
Fine, but give me a program in any programming language, be it "text-based" or "purely graphical" and it's probably possible to translate it into a representation that's vice versa. (Problems arise when a representation is too abstract: ambiguity can occur.) Program representations are like city maps. There's only one city, but there are many maps: the subway map, the map of post offices, the map of gas lines, the map of Wi-Fi coverage, and so on. I will agree that different representations have different capabilities and use cases. However, text is also capable of great abstraction, e.g. z2 = BesselJ(n, z1)
- mbrock 13y ago
  You're kind of stretching the definition of "language," though. Programming language grammars are defined textually. Do you think, for example, that a (useful) pictorial representation of Haskell code can be derived simply from the language grammar? Sure, the map is not the territory, but you can also say the language is itself the map, and the territory is something way more abstract, like "computation." Perhaps you can take the semantics of Haskell and invent a graphical syntax for it, perhaps even strongly inspired by the textual syntax of Haskell. But it wouldn't be straightforward, and any obvious, straightforward attempt would probably be terrible. In other words, I don't think it's obvious that there is a "deep structure" of programming languages that can be worked on directly in a wide variety of formats. Unless you count the AST as such a structure, in which case graphical programming is reduced to graphical tree manipulation (which admittedly is the path taken by many of these examples).
  - nitrogen 13y ago
    Dataflow languages (like the one I developed: http://www.nitrogenlogic.com/docs/palace/ http://www.nitrogenlogic.com/docs/palace/) seem like they would have a fairly straightforward mapping to/from a purely functional language like Lisp.
    - mbrock 13y ago
      That looks cool! By the way, the more I think about this, the less I seem to know even what a "language" is. Is Lisp a language? No, it's a family of languages, but even Scheme is a language known for its minimal grammar and its infinite extensibility. A common critique says that one programmer can't understand another's Lisp code because there's such a great potential for redefinitions and domain-specific syntactic extensions. If Lisp has a slogan, it's "code is data." Is Lisp a meta-language, or even an anti-language?

ericHosick 13y ago

If you really get to thinking, programming is all about abstraction. We talk about abstract concepts like functional programming, object oriented programming, structured programming, objects, functions, methods, inheritance, etc. But, in the end, it's all just playing around with stack pointers, instructions and malloc. As Permit points out here (https://news.ycombinator.com/item?id=7274956 https://news.ycombinator.com/item?id=7274956), a large part of a programmers job is to build a "mental model of their program". We abstract things and come up with constructs to represent these abstractions to make it easier for us to program a computer: to improve on our mental model. So, we come up with different programming languages and label them by their approach. This is a functional programming language, this one is declarative, this one is procedural and this one is visual. My 2 cents.

dinkumthinkum 13y ago

No I think you're being sort of outlandishly ridiculous .... just to be honest. You would have us not allow for any sort of classification of programming languages then because they are Turing complete.

troymc 13y ago
It's fine to classify programming languages. It's not fine to get confused between a programming language and a way of representing a particular program. For analogy, there's only one true physical Earth, but there are many possible maps (representations) of the same area: one showing the temperature at the surface (using color), one showing wind direction at various points, one showing roads, etc. Which map is correct? Which map is best?
- greatsuccess 13y ago
  But a programming languages goal is to make the Earth. Not to represent it.
- dinkumthinkum 13y ago
  Your analogy doesn't really make sense. What we are doing is saying: "This is an object language, this one is functional, this one is visual." Again, your problem seems to be more one of not wanting us to call any programming language with any adjectives differentiating it from others ...

spyder 13y ago

I agree, they should be called "visual programming environment"

agumonkey 13y ago

To me it's neither of them. I don't know how I'd call that, semantic .. ontologic ? The 'text' is as much an interface to the abstract model as the 'visual'. When I see repls with sophisticated real-time output representation it's as much visual as dataflow programming by connecting nodes to an output sink. Brett Victor's work is bringing them even closer since usually dataflow/reactive was used in mathematical settings (time varying scala or scalar arrays... image or sound) but he demonstrated far more the benefits in non linear logic (games). It's the disconnected, char per char ascii, file saving, build time, run time tradition that creates an artificial segmentation.

chevreuil 13y ago
Relevant Bret Victor video : https://vimeo.com/66085662#t=9m20s https://vimeo.com/66085662#t=9m20s
- agumonkey 13y ago
  Can't be clearer. ps-edit: of course he's always clearer, that's why we watch his talks.

twelvechairs 13y ago

This is exactly why most 'visual programming languages' don't take off - because they fixate on a single means of repreaentation - which will never cover all use cases (and text representations can cover the same territory just as well) rather than doing what they should do - allow varied representations of programs.

vorg 13y ago
Yes! All language, whether natural or programming, can have two primary structures: semantic and thematic (these are terms from Linguistics). Thematic structure (very roughly) refers to the effect of the writer, the medium, and the reader/s, which explains why one semantic structure can be represented in a variety of ways.

NAFV_P 13y ago

> 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"? If C was represented in an olfactory manner my code would be deemed a bio-hazard.

aaronem 13y ago
Certainly lends new meaning to the concept of "code smell".
- NAFV_P 13y ago
  "Damn, your code stinks man!" I have never happened across this bizarre piece of jargon, but I goooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooogled it, cheers.

coldtea 13y ago

>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.

jimbokun 13y ago
"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.

jimbokun 13y ago

The project I work on has a custom querying DSL, and recently we have been working on a visual query builder for this language. So this is a very concrete example of a language with both a textual and visual representation. Of course, keeping fidelity between both representations can be a challenge. Our design could be improved by being more diligent in sharing the same underlying model for both. I imagine there are other cases like this, where you have a visual tool for building expressions for some textual language. (Are there SQL tools like this? Seems likely there would be.)

aufreak3 13y ago

At its core, a programming environment provides a link between a formal system and some aspect of our world. You could think of a general purpose Computer as providing a link between any formal system and the aspects of our world that it ties int, but we can limit ourselves to programming environments for simplicity of discussion. With that perspective, we can ask what representations of a formal system do we find easy to manipulate in ways that produce results that are significant for us (in a specific problem context). A visual representation would certainly be a better match for a spatial problem domain (Sutherland's work, for example). Similarly, an audio representation can work well for an audio domain (ex: beardyman's realtime performance system he presents in his ted talk). Likewise, I'm quite sure a system for exploring cuisine art would match a "smell representation". The notion of a "universal turing machine" guarantees that all of these representations can be mapped to that of a symbol stream. That is a mathematical result, but which representations appeal to humans involved in various kinds of work is not a mathematical question - it is a HCI question.

MSF2014 13y ago

(1) Look at CPWCT, a visual programming language (based on the C programming language, and developed/used inside Programming Without Coding Technology (PWCT) See this online movie to get quick idea without downloading the software : http://www.youtube.com/watch?v=461iVUl08mQ&list=PLpQiqjcu7CuHg6IRXVdt9MILiHG7JSVq7&index=24 http://www.youtube.com/watch?v=461iVUl08mQ&list=PLpQiqjcu7Cu... When you see this movie you will discover the difference between a Visual Programming Language like CPWCT and a text-based programming language like C (2) When we use a text-based programming language, think of this using ( command-line / terminal ) of the operating system instead of using the GUI to do your tasks. (3) Designing a visual programming language is an art (more complex than designing a text-based programming language) because the user interface of the visual language is more advanced. (4) Using a Visual Programming Language, we can see the visual representation text in natural language (English, French, any other language) and we can change the visual representation and we can allow the programmer to change the visual representation (not easy to allow the programmer to change the syntax of a text-based programming language, we can do this, but the programmer will need to recompile the lexical analysis program, and it will be another language that can't recognize programs that are written using the old syntax, while in visual language we can allow this customization and we still open any programs create before or after this customization). (5) We can add more dimensions to the visual programming language (like the time dimension). this dimension is not known to text-based programming language. you can move forward/backword during application construction process, and you can run programs in the past, you can see a movie of how to create the program step by step See this movie : http://www.youtube.com/watch?feature=player_embedded&v=wpxbfPxNHqg http://www.youtube.com/watch?feature=player_embedded&v=wpxbf...