Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!psuvax1!brutus.cs.uiuc.edu!sane From: sane@brutus.cs.uiuc.edu (Aamod Sane) Newsgroups: comp.lang.visual,comp.lang.misc Subject: Re: metaphor and programming Message-ID: <1989Nov15.063815.1949@brutus.cs.uiuc.edu> Date: 15 Nov 89 06:38:15 GMT References: <13770@orstcs.CS.ORST.EDU> <5623@ogccse.ogc.edu> Sender: news@brutus.cs.uiuc.edu Organization: U of Illinois, CS Dept., Systems Research Group Lines: 117 dinucci@ogccse.ogc.edu (David C. DiNucci) writes: >In article <13770@orstcs.CS.ORST.EDU> budd@mist.CS.ORST.EDU (Tim Budd) writes: >>[order of presentation reversed - near end of article, Tim says] >>My thesis is that this is so because the metaphors we are using are >>basically not visually oriented to start with, and forcing them to be so >>necessarily results in the problems I mention. >>[near beginning, Tim says] >> >>thesis 2) radical changes in programming languages occur when new >>metaphors are introduced. (witness logic programming, witness object >>oriented programming). >> >>What do I mean by metaphors? Here is a partial list. >>I would welcome any additions (particularly given my note at the end). >> >>2. The flow model. Computation is modeled on a flow of data being directed >>and modified over space. Programming is the process of putting together >>conduits for flow in different forms. >> experiences: electronic circuits, water pipes, tinker toys, >> examples: data flow languages, functional languages. >> >Are you saying that this is not a visually-oriented metaphor? All >reasoning in all of those "experiences" you mention starts with the >eyes. The problem with visually presenting a data flow or functional [.. dataflow diagrams and presentations etc...] >So, my claim here is that the metaphor isn't bad, but we shouldn't >apply it to things that can be better represented using other methods. I would think that the design phase where you really use the metaphors is not so visual, or precisely experienced through the eyes. It is more of a consolidation and presentation time thing. The thing with metaphors is that they help you to structure the associations in your mind. (I am not quite able to put this in words) And do it better than diagrams. >>3. The autonomous agent model. Programming is modeled on a delegation of >>responsibility to a variety of more or less autonomous agents. Computation >>involves setting up the agents, and then having them interact. >> experiences: most real world interactions >> examples: object oriented languages >> >The only reason that such agents are considered "autonomous" is that >their interaction is not usually visualized! If it was, we could The autonomy is in the density of interactions within and between objects. Also that they are a semantic unit. The visualisation idea here would work in the form of painting. We need icons which can be composed as easily as a painter puts together images of natural objects.Making a landscape out of mountains,trees sky and clouds. >>5. The declarative, or inference model. Programming consists of writing >>lists of facts and rules of inference. Computation involves the answering >>of queries. >> experiences: geometry, logic >> examples: prolog, other declarative systems. >> >Logic also has a visual component - a proof is a DAG, where the vertices >are true propositions and edges are inference rules. Also, if we make the Such a dag is perhaps too complex to be of any use visually. >>Now on to my thesis 3. I have observed that visual programming, that is >>programming in a visual manner, has not been as successful as one might >>have hoped. At first, the common thought is ``people are basically >>visual'', or ``a picture is worth 1,000 words''. But actual visual >>languages tend to be either (1) hard to use, (2) fun, but no more >>productive than conventional languages, or (3) limited to very narrow >>domains. We don't have a general purpose language of the flexibility, >>power, and ease of use of say Pascal. >> >hide the complexity (where we must) inside programs written with standard >textual languages, and leave only the interactions between these programs >out where they can be seen. >and though I have customized both the textual and graphical syntax of the >language to suit my tastes, I ALWAYS find myself writing programs in it >graphically. (Now if I can just find someone to implement a nice graphical >Dave I agree. At some level, the visualisation must stop. To use the painting metaphor (See what I said about metaphors ;-) at some level you are left with strokes of paints, not object representations. I would also like to add, I don't think in writing functional programs we think of data flow as such. It is more a composition, a algebraic formula approach. This is nice because we learn a lot to think like that in maths. I do think visually while solving problems, but more often it is a case of Oh! this formula fits!. (Disclaimer : I am not someone working in visual programming, or functional. I just thought this discussion was interesting. So please point out any bloomers, or repititions of ideas well known to experts who might be reading this. (eg "painting")) Aamod Sane