The result was disambiguate. King of ♥ ♦ ♣ ♠ 02:34, 2 May 2011 (UTC)[reply]
No assertion of notability, unreferenced, and lacks clear focus on a single topic. Diego Moya (talk) 23:17, 21 April 2011 (UTC)[reply]
"Graphical language" should be separate, focusing on formal, graphical modeling languages used on computers. These are common, for instance for workflows - reference the BPMN article in Wikipedia. They are also used in monitoring and control, as in the GDA reference cited, or in the "Sequential Function Chart" article in Wikipedia (based on the earlier GRAFCET graphical language, used for PLCs), or in the graphical language used as cited in the Wikipedia article on LabVIEW. While the current "graphical language" page is currently a bit of a hodgepodge that needs focus, it still differs from the "visual language" article. The "visual language article is even more of a hodgepodge of psychology, art, etc., focusing on how humans interact with each other.
used on computers are not really visual programming languages, though. To me, a real "programming language" generally emphasizes specification of a series of steps - it is basically procedural (although some of those procedures are what to do to respond to events, etc.). But some modeling languages are truly declarative. That is, they don't specify steps. They are typically a model of some aspect of the real world or perhaps a computer application. As an example, consider a graphical language that allows someone to represent a fault tree graphically. That's a completely declarative representation of how faults propagate, e.g., how various root causes of something like loss of coolant in a nuclear reactor propagate to cause the loss of coolant, and then propagate further leading to release of radioactive gas, etc. That model stands by itself independent of its usage. It could be used for prediction -- e.g., mark a valve as stuck, and follow the implications to see what will happen. Conversely, hypothesize an event like loss of coolant, and trace back through the diagram to figure out what might have caused it. Or, estimate the future probabilities of events based on the probabilities of failures of each of the root causes. The point is that different "engines" treat the same graphical model differently, even though it's the same model. It's up to an "engine" to decide what to do with that model. (I've been involved with graphical languages that make multiple uses of given graphical models.) A workflow representation like BPMN is a representation of something that is essentially procedural, so might be considered a graphical programming language, but not all graphical languages are like that. Gmstanley (talk) 19:21, 27 April 2011 (UTC)[reply]