4 ms·

Except that: - most text-based programming languages have no purely graphical counterpart. - Most purely graphical programming languages have no purely textua

by 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?
    - deleted 13y ago
      [deleted]
bergie 13y ago
NoFlo has a textual format as well as the visual one seen on the article: http://noflojs.org/documentation/fbp/ http://noflojs.org/documentation/fbp/
- slacka 13y ago
  It's a shame people reject dataflow languages because they associate it with visual programming. Dataflow languages can be textual, visual, or a combination. It's good to see that NoFlo has exposed the textual side. Like functional programming, one of the key benefits of dataflow programming is that it is inherently parallel. With the coming 16-core CPUs, GPU, and project like Parallella, this becomes even more important.

by Renaud 13y ago

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?
  - deleted 13y ago
    [deleted]

bergie 13y ago

NoFlo has a textual format as well as the visual one seen on the article: http://noflojs.org/documentation/fbp/ http://noflojs.org/documentation/fbp/

slacka 13y ago
It's a shame people reject dataflow languages because they associate it with visual programming. Dataflow languages can be textual, visual, or a combination. It's good to see that NoFlo has exposed the textual side. Like functional programming, one of the key benefits of dataflow programming is that it is inherently parallel. With the coming 16-core CPUs, GPU, and project like Parallella, this becomes even more important.