Path: news.media.mit.edu!bloom-beacon.mit.edu!spool.mu.edu!sgiblab!munnari.oz.au!foxhound.dsto.gov.au!fang.dsto.gov.au!yoyo.aarnet.edu.au!ntx.City.UniSA.edu.au!magill.magill.unisa.edu.au!kerrb From: kerrb@magill.unisa.edu.au Newsgroups: comp.lang.logo Subject: Re: Evolution of logo Message-ID: <1994Jan1.140735.97@magill.unisa.edu.au> Date: 1 Jan 94 14:07:35 +1030 References: <1993Dec24.194331.91@magill.unisa.edu.au> <2ff56r$l29@agate.berkeley.edu> Organization: University of South Australia - Magill Lines: 214 I still think logo has an ambiguous feel to it. But my attempts at explanation have been effectively countered so here is a new attempt. My uncritical acceptance of Brian's reformulation of my original post did not help my case. This reformulation was: graphics=easy=intuitive VERSUS lists=hard=formal The worst part of this formulation is the easy v. hard dichotomy. Once I linked easy to intuitive I was implicity downgrading intuitive because as a given some parts of learning are not easy. Hence I was slipping into the dominant computing / maths culture that equates formality or abstraction as essential for higher order learning tasks. That is *not* what I am trying to argue. What I am trying to argue is that hard tasks can be accomplished with non traditional learning styles. The dichotomy of learning styles that I am suggesting goes something like this -- PLANNERS (dominant in computing cultures) Metaphors -- abstract, formal, hierarchical, planners, rule driven, rational, algebraic TINKERERS (marginalised in computing cultures) Metaphors -- concrete, negotiated, heterarchical, ad hoc, tinkerer, bricoleur, improvisers, intuitive, transparent. The question I am asking about the future evolution of logo / Boxer / OOPs is that is there anything inherent about the enterprise of programming or mathematics that makes advanced learning tasks (recursion, eg. writing your own recursive reporters) inaccessible to those with a preferred tinkerer learning style. What I mean about the ambiguous feel of logo as presently designed is that turtle graphics (including simple recursion) accommodates different learning styles whereas more advanced list processing (Chapter 7 if volume 1 of Brian's book) does not. I found Chapter 7 difficult I think for these reasons. I began to lose the feel of it when it came to writing recursive operations using output. If I have a bug in recursive commands (print instead of output) then the way I cope is to put a trace in and that helps me track it down. But the trace doesn't help with recursive operations (or I don't know how to do it) and so I lose the feel of it. Obviously my style here is concrete, negotiated and I feel comfortable working with it if I can track bugs in this way but once it becomes like an impenetrable black box then I lose the feel of it. It feels alien, not me. This would not be a problem for those with a PLANNERS learning style because they are building naturally, taking another step with their preferred style. What I am suggesting is that those who are not planners are likely to lose it at this stage and this represents half the population. Hence it is desirable for logo to evolve further in its design using visual and OOPs features to accomodate half the population. This is more likely to work than exhortations to teachers about the one and only true way. I don't believe there is one true way. It is more an artifact of the cultural dominance of one particular style in present computing cultures. In article <2ff56r$l29@agate.berkeley.edu>, bh@anarres.CS.Berkeley.EDU (Brian Harvey) writes: > kerrb@magill.unisa.edu.au writes: >>Is this fair comment? >>The designers of logo have grafted an intuitive learning environment (the body >>language of the turtle) onto a core (LISP LIST processing) that needs to be >>learnt in a formal, counter-intuitive manner?? > > I don't believe that that's true either. If anything, I think that people's > expectations are higher about natural language program results than about > graphics program results. That is, a beginner is really happy (and so is > his or her teacher) to get a square on the screen, which you can do just > by typing a few separate instructions. But people aren't so excited if > you do something like > > print [Shall I compare thee to a summer's day?] > print [Thou art more lovely and more temperate.] > > and so on. (That's all I remember :-) Meaningful and powerful turtle graphics microworlds can be created fairly easily. to poly :angle fd 50 rt :angle if heading = 0 [stop] poly :angle end This can be explained concretely. eg. by a role play. To achieve equivalent power and meaning using natural language requires considerable more effort. eg. Chapter 4 / 5 of Goldenberg and Feurzeig. There are other cultural reasons why teachers will be unlikely to go down this track. > > As soon as you get past drawing a size-100 square, and want to draw > either a variable-size square or some more exotic shape, like a spiral, > the notation is no less counterintuitive than in the case of text, > because it's the *same* notation, and raises all the same issues. > Recursion, for example, is pretty counterintuitive, but Logo teachers > find ways to deal with it -- talking about little people, and so on. > The question of when you put Logo expressions inside brackets (as in the > example of IF) comes up in graphics, too. And remember my example about > trying to abbreviate SETPOS; that was a graphics project. > Talking about little people, role plays, traces are concrete way of teaching recursion that will make it accessible to the TINKERER style described above. > I think if you're going to call formal methods counterintuitive, then > Logo turtle graphics is already on the wrong side of the line, and what's > really intuitive is a paint program! (But formal=counterintuitive makes > me nervous, too; for me it's quite the opposite. I'm happier with formal > methods than with freehand drawing -- and in the text domain, I write > nonfiction about computers, rather than novels.) > > I guess it is true that composition of functions is counterintuitive > to nonmathematicians. And graphics programming is mostly full of commands, > whereas natural language programs have a lot of operations. This is why > the LogoWriter fans like to do natural language by using the screen as a > character array, so they can write Pascal-style programs to manipulate text > through commands rather than operations. > > What I mean is, if they want to form the plural of a word, instead of saying > > to plural :word > output word :word "s > end > > they say > > to plural :word > ct > insert :word > insert "s > top > select > eol > output selected > end > > or something like that. Probably they wouldn't do it for such a simple > situation, but you get the idea. (Often you don't even have to output > the result; you could just say > > to plural :word > insert :word > insert "s > end > > and that's exactly comparable to turtle graphics programs.) I don't understand the point because LogoWriter can be used to write recursive operations. What is inherent about LogoWriter than is encouraging people to adopt what Brian sees as inferior programming style (commands rather than operations). The central issue is to devise better methods to teach people how to program more powerfully. ie. incorporate visual and OOPS features into a future evolution of the language. > > Many people find programming with commands easier than programming with > operations, because they're unfamiliar with the idea of *functions*. > It has nothing to do with notation, or even really with formalism, but > rather with mathematics; you have to learn to think of composing functions > as a natural activity. I think that that's hard but worthwhile, just as > learning to think recursively is hard but worthwhile. I have tried to clarify this -- can hard stuff be learnt using the tinkereres style. > >>Programmers are normally formal, algebraic, mathematical types with a top-down >>planner learning style. What is the best programming language around at the >>moment that will accomodate other learning styles and is also accessible to >>school children? > > I would prefer to pose the question a little differently: How can we best > accommodate all children and *bring them to where formal methods are > accessible to them*? Because if you just assess what the kids already > know, and give them tools they can use from there, then you aren't teaching > them anything! The whole idea of Logo is to introduce kids to the language > of mathematics -- that is to say, formal language. This reformulation of my question implies a mind set that says formal is better. I don't accept that at this stage. I thought the whole ideas of logo was to transform traditional subjects like maths to better fit the learner. ie. epistemology is about the evolution of learning structures in our mind. Logo is about making it more natural, not imposing traditional formal methods. > > Boxer and Microworlds both have certain advances that night make the first > steps a little easier, but fundamentally I don't think there is a magic > bullet for this. I think no matter what language you use, there comes a > point at which you have to make the leap into formal thinking. There is no magic bullet to make it easy. But are there ways to make it more accessible to tinkerers and their natural learning style.? Is this true? Papert and Turkle presnet a different case in their article about 'Epistemological Pluralism' > To be entirely honest, it's probably easier in a conventional language, > such as Pascal or Basic (or Hypertalk, which is trendy right now), in > which there is a clear distinction between program and data. Then you > don't get issues like the IF syntax issue; IF is strange because a piece > of Logo program is used as an input, as a datum. The old-fashioned > IF...THEN... syntax avoids that. The advantage of the Logo way is that, > again as in the case of recursion, the technique of program-as-data is a > very flexible one that empowers you once you learn it.