Xref: utzoo alt.hypertext:846 comp.graphics:17263 comp.multimedia:362 comp.software-eng:5362 comp.cog-eng:1953 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!uwm.edu!psuvax1!rutgers!rochester!pt.cs.cmu.edu!o.gp.cs.cmu.edu!andrew.cmu.edu!mk3c+ From: mk3c+@andrew.cmu.edu (Melinda J. Klump) Newsgroups: alt.hypertext,comp.graphics,comp.multimedia,comp.software-eng,comp.cog-eng Subject: Re: Images vs. Text Message-ID: Date: 16 Apr 91 10:47:13 GMT References: <1991Apr2.180348.19733@smsc.sony.com> <1991Apr02.235121.17834@convex.com>, <34980@athertn.Atherton.COM> Distribution: na Organization: Class of '91, Carnegie Mellon, Pittsburgh, PA Lines: 115 In-Reply-To: <34980@athertn.Atherton.COM> Scott McGregor Asks: 1) Is, as is the authors claimed above, a pictorial programming language "*equally* acssible to users from all linguistic backgrounds"? Or does it skew the field the other way (i.e. against Indo-European language users)? I think it has to do more with cultural connotations of pictures rather than the language behind the culture. 2) Is the concept of a variable really more difficult to users of ideographic language users? How are other mathematical uses of variables taught? Does mathematical literacy negate this alleged deficit? When you think of numbers (and +/-* type symbols) as one language, and letters another, this conflict is lessened. If we only had numbers to work with when trying to form a mathematical formula and couldn't use letters to represent variables, then we would have a problem. Which leads into your question on meaningless strings... 3) If the availability of meaningless strings is the key to use of variables, why is it so important to choose meaningful names for variables instead of nonsense or conventionally meaningless names such as "X"? It isn't "so important" but it lessens one step in translation. If I told you that a + b = c and I told you that red + blue = purple, which one would you understand faster/easier/more meaningfully? (This same equation could be used totally pictorally using squares of red and blue and purple for example) 4) Would you like to use such a pictographic programming language? Why or why not? Inquiring minds want to know... No more than I would LISP, which I am currently learning, and which I believe is entirely bogged down in words' meanings. Which shows that the pre-conceived "meanings" of the strings gets in the way of my learning and implenting the language, much like the chinese problem, except this is the indo-european version. There is also no known universal pictorial language that can express the same number of basic concepts that exist in English or Chinese ( or any other language type) that wouldn't make my task twice as hard to learn a language that could be expressed in a language I already use as my basis for communication. I would have to learn the pictorial language first, then the programming that uses it. An ideal language/alphabet would be one that combined aspects of both: for example as one that does this somewhat, Sanskrit I believe uses a horizontal line (icon) to represent the root/basis of a word, with consonants below the line and vowels above. Using that rule alone, I could semi-decipher Sanskrit a lot more than than I could English that has no universal visual key like that: all the vowels look different and can be placed anywhere. That also brings up the concept of dimensions with language: Sanskrit utilizes a horizontal and vertical axis to express itself. An icon-string hybrid language would also have to utilize such to give it enough flexibility to be representative/useful. One could visualize a sheet of graph paper with the narrative/programming beginning either in the center or one of the corners and continuing in whatever other directions thereafter. As an example: We are programming in the hybrid language on a graph with the axis in the center of the paper/screen. The upper left corner defines the variables, the more global, the closer to the center. Functions are in the upper left, global variables centralized again. The "body" (an example of present visual keys in a non-visual language today) is in the lower left. Programming in this fashion allows us to program non-sequentially if we want to. Visual clues and language do/can not limit themselves to one dimension Scott McGregor As a user and not a programmer observing this discussion: I use Macs a lot. They are very easy to use using windows and icons. But I can't use my macintosh without the words (under/with) the icons to explain which sub-set I am using. I have about 10 art programs in my files, and I use different programs for different pieces (depending on what I want to do). I save all my programs on one disk/folder/storage area and my art on another. It is easy to sort out all of my files using pictures within pictures (icons in folders in folders for example) using a nesting or branching looking process/set-up visually. I have 25 pieces of art in one file, 7 being A program, 8 being B, 3 - C, 4 - D, etc. All art programs have universally (for the most part all types of programs) picked an icon to represent a "document" : a page of paper with a corner folded down. Then I can sort out my programs from my documents. I couldn't however, sort out my A documents from my B documents based on that alone. So the programmers have sub-iconed each icon with an icon inside to represent that it was an A program that created it, or a B document, etc. One thing I have come across as a difficulty though is a "generic art " or "pict" document: it has no sub-icon, just the icon of "document". So consequently, I cannot tell that it is an art document by looking at it. Now if all art programs adopted a universal sub-icon that showed it was an art document first, then they used a sub-sub-icon to show what program created it, my life would be a lot easier. Nesting and branching is the key to happiness :-) That is my example/problem/boon with icons so far. michael j pastor iii guest on melinda's account