# Lambda the Ultimate

 Readership skills and graphical programming started 11/11/2001; 1:50:15 PM - last post 11/12/2001; 7:37:03 PM
 Ehud Lamm - Readership skills and graphical programming   11/11/2001; 1:50:15 PM (reads: 737, responses: 5)
 Readership skills and graphical programming Marian Petre Why looking isn't always seeing: readership skills and graphical programming Communications of the ACM, Volume 38, Issue 6 (June 1995), Pages: 33 - 44. Abstract: Many believe that visual programming techniques are quite close to developers. This article reports on some fascinating research focusing on understanding how textual and visual representations for software differ in effectiveness. Among other things, it is determined that the differences lie not so much in the textual-visual distinction as in the degree to which specific representations support the conventions experts expect. This paper is related to our recent discussion on visual languages. The paper is not online (outside the ACM DL), but Oleg kindly provided a summary. Posted to general by Ehud Lamm on 11/11/01; 1:56:40 PM

 Ehud Lamm - Re: Readership skills and graphical programming   11/11/2001; 1:54:22 PM (reads: 763, responses: 0)
 In fact, there are "graphical" languages which are formal, e.g., proof nets in linear logic, Hasse diagrams for posets, commutative diagrams in category theory, term graphs... It seems you're speaking about a primary notation -- which is indeed formal. Which arrows go to which vertices is a primary notation. Let's take an example of a diagram with three objects, A, B and C and two arrows A->B and A->C. We can draw the diagram as follows: ``` A --> C A | / \ V / \ B B C Fig. 1 Fig. 2 ``` (There supposed to be arrows from A to B and from A to C on Fig. 2). We can connect vertices with straight lines, bent lines or squiggly lines. The set of vertices and the set of arrows -- the primary notation -- is the same in all these cases. The layout, the secondary notation, is different. We usually would draw a symmetrical diagram, like the one on Fig. 2, to indicate that arrows A->B and A->C are semantically "equal". To make the example more concrete, let's assume that A, B and C stand for the names of C++ classes, with arrows indicating dependencies. That is, if class A is modified, both B and C have to be inspected for potential conflicts, and the corresponding code must be re-compiled. If both B and C inherit from A, we would likely to depict the dependency relationship as in Fig. 2. If, however, class B inherit from A but class C includes an object of class A, we would likely to draw the dependency graph as in Fig. 1. In both cases the dependency information -- the primary, the formal semantics -- remain the same. They layout, if done intelligently, gives us additional hints. The secondary notation is present even in textual languages. For example, the following two snippets are equivalent ` while( (c=getc()) != EOF && isspace(c) );` and ``` while( (c=getc()) != EOF && isspace(c) ) ;``` yet the latter is more comprehensible. To a human reader, not to the compiler. A compiler won't mind if we name all identifiers as i1, i2, i3, ... Well-chosen names however give a human reader a deeper insight into a piece of code. It takes some practice in a programming language to typeset it lucidly. BTW, people often post source code snippets on comp.lang.scheme and similar groups. You can almost instantly spot code posted by a novice -- by the layout of the code. Of course the are "rules" of layout, which are mostly the rules of thumb. Sometimes it's necessary to break them for one reason or another. It takes practice to grasp these reasons. In visual languages, the layout is far reacher, and is far more difficult to formalize. It takes longer to learn and to master.