User loginNavigation |
archivesWhy a diagram is (sometimes) worth ten thousand words
Jill Larkin and Herbert Simon, Why a diagram is (sometimes) worth ten thousand words. Cognitive Science, 1987.
The advantages of diagrams, in our view, are computational. That is diagrams can be better representations not because they contain more information, but because the indexing of this information can support extremely useful and efficient computational processes. But this means that diagrams are useful only to those who know the appropriate computational processes for taking advantage of them. Furthermore, a problem solver often also needs the knowledge of how to construct a "good" diagram that lets him take advantage of the virtues we have discussed. In short, the ideas we have presented, not only provide an explanation of why diagrams can be so useful, but also provide a framework for further study of the knowledge required for effective diagram use. While this paper is not about programming languages, it describes research that may be relevant to the discussion of visual programming languages versus textual languages as well as other language design decisions. Seeing as human factors were recently mentioned, and that it seems to be cognitive-week here on LtU, I thought this paper might be of interest. While I am sure this paper can be discussed from many angles, I'll only mention two. 1. While this paper is old, I still find it remarkable how old fashioned it seems. I am not sure exactly what causes it to feel this way; probably something in the writing style. 2. While I haven't searched the literature, I don't recall seeing research on programming languages that uses the framework suggested by this paper even though Simon's work was, of course, well known to computer scientists in general, and PL researchers in particular. Target Backend for a Uniquely Typed LanguageI'm currently designing a small, uniquely typed language for a masters project. So far the semantics is pretty well mapped out and I'm looking for a suitable backend to compile to. Although the language has been designed as an imperative language with referential transparency, it can be translated fairly directly into Haskel, however doing so loses most of the benefits of having uniqueness typing, i.e. object lifetime can be determined at compile time meaning no garbage collection and safe destructive updates. I'd like to find a suitable backend/vm to compile to that will allow me to take advantage of these properties. It would be nice to be able to include laziness and implicit parallelism too, although neither is essential and are perhaps beyond the scope of my project. Having said that, a backend that supports concurrent programming would be very useful, as uniqueness typing allows for an interesting model of concurrency without deadlocks or race conditions.... I can happily provide more concrete information on the language (I should really give it a name) if needed, I'm not sure of the kind of thing that's important to consider. A previous discussion on this site talked about how linear languages can be compiled using stack machines and permutations, so some sort of stack based vm might be a good idea. Thanks! Mental animation: Inferring motion from static diagrams of mechanical systems.
Hegarty, M. (1992). Mental animation: Inferring motion from static diagrams of mechanical systems. Journal of Experimental Psychology: Learning, Memory and Cognition, 18(5) 1084-1102
Reaction-time and eye-fixation data are analyzed to investigate how people infer the kinematics of simple mechanical systems (pulley systems) from diagrams showing their static configuration. It is proposed that this mental animation process involves decomposing the representation of a pulley system into smaller units corresponding to the machine components and animating these components in a sequence corresponding to the causal sequence of events in the machine's operation. Although it is possible for people to make inferences against the chain of causality in the machine, these inferences are more difficult, and people have a preference for inferences in the direction of causality. The mental animation process reflects both capacity limitations and limitations of mechanical knowledge. Following the theme of yesterday's post this is another non-PL research paper that explores cognitive factors that might be relevant to programming language design. The research in the paper nicely illustrates how different accounts of the cognitive processes involved in reasoning about the behavior of a mechanical system or model can be compared experimentally. The results suggest the types of inferences that are involved in mental animation of the type requested from the subjects, and how they are orchestrated. The first section of the paper provides the general framework, and explains the notion of mental animation. A discussion of the generality of the results can be found at the end of the paper. Those who find my last two posts too far removed from PL issues need not worry; I am not going to post more research of this type soon. Those who are intrigued by this research will be happy to know that a lot more is available where this came from. |
Browse archivesActive forum topics |