logo

[Bill_Powers1]

[From Bill Powers (970820.1353 MDT)

I downloaded MWSLogo and have been looking at it. I don't have any books on
it, but before going any further I thought I'd ask people on the net what
they think of it as a programming language to teach my grandchildren, who
speak English. I can see that it works nicely for drawing lines on the
screen (repeat 4 [forward 100 right 90] makes a square), but the rest of it
looks pretty strange. It's hard to imagine a child figuring out what to do
with lists and lists of lists, and commands where you have to memorize ten
arguments some of which are numbers, some lists (of something) and others
commands.

I looked at the introductory stuff that is on the Web, but it all stops
with drawing lines. The operations for doing things like moving little
figures around on the screen, which might be fun, are so complex, what with
making bitmaps, cutting out masks, and reading bitmaps, that I wouldn't
know how to start teaching them. The learning curve seems nice and shallow
for the first few steps, and then it takes off practically vertically. Or
so it seems to me, an old procedural programmer. My main feeling is one of
getting cut off from contact with the machine, and starting to work through
someone else's mind.
Is the world really made of lists of lists of lists? Someone, it seems, is
stuck at the sequence level.

I once took a course in LISP, but I don't remember much about it except all
the parentheses. Any comments?

Best,

Bill P.

[Wolfgang_Zocher2]

From Wolfgang Zocher (970821.0830 MEZ)

Hi, Bill --

[From Bill Powers (970820.1353 MDT)

I downloaded MWSLogo and have been looking at it. I don't have any books on
it, but before going any further I thought I'd ask people on the net what
they think of it as a programming language to teach my grandchildren, who
speak English. I can see that it works nicely for drawing lines on the
screen (repeat 4 [forward 100 right 90] makes a square), but the rest of it
looks pretty strange. It's hard to imagine a child figuring out what to do
with lists and lists of lists, and commands where you have to memorize ten
arguments some of which are numbers, some lists (of something) and others
commands.

Logo is a sort of Lisp and so the only known datastructures is the list.
But this normally makes no trouble. Thinking about lists and lists of
lists is as complicated or uncomplicated as thinking about arrays and
referencing array elements in other programming languages..

I did a lot with logo and children (4-8 years old). By drawing lines (see
your "square example" above the kids can learn HOW to program a computer.
The results of their efforts are nice drawings on the screen - not
numbers. Modern concepts of programming (modular programming; functional
programming) are learned on the fly: make a function which draws a square
and then make a new one, which rotates this square around one corner point
The kids can define functions (new logo words which get the turtle to know)
and then they can play with these functions to generate complex drawings.
In a seminar on two weekends the kids came thru to recursive procedure
calls - try this with C or Basic ...

Best,

Wolfgang Zocher

email: zocher@rrzn.uni-hannover.de (office)
       zzzo@apollo.han.de (home)
www: http://www.unics.uni-hannover.de/rrzn/zocher

[Bill_Powers1]

[From Bill Powers (970821.0849 MDT)]

Wolfgang Zocher (970821.0830 MEZ)--

Logo is a sort of Lisp and so the only known datastructures is the list.
But this normally makes no trouble. Thinking about lists and lists of
lists is as complicated or uncomplicated as thinking about arrays and
referencing array elements in other programming languages..

I guess I'll have to get a book on Logo. Righr now I have trouble thinking
about datastructures that are sequentially ordered as a basic property
(that's the eighth order of perception in HPCT!). There must be some way to
let you access the elements of a list randomly -- that is, to bypass the
sequential ordering, and make the list look like an array. Also it seems
unnatural to have logical structures embedded in lists instead of the other
way around. But maybe I'm simply revealing the private biases that led me
to define the levels as I did! Or maybe I don't understand Logo (or Lisp)
yet.

I have problems with object-oriented programming for similar reasons. I
think of objects as things with properties, without any particular
operations connected with them. It reminds me of the arguments on the net
about the "purpose of a lawn-mower." If you make "cutting grass" part of
the definition of a lawn-mower, you can't use the lawn-mower, as a physical
object, to hold the garage door open. You have to define a new object for
every new use you think up. I know this is easy to do through inheritance,
but why should we have to do it at all? I don't like programming languages
that impose a structure on the way I use them right from the start, so I
have to outwit them to do what I want.

I had similar feelings about Forth. It's a neat language in some ways, but
that stack makes it awfully hard to retrieve things that have been buried
in it. You have to keep a separate map in your head, and if you get
confused, it's very hard to reconstruct the picture of what is where. It's
like having a memory in which there are no addresses. The stack reminds me
of the way that rotating platform in the middle of my dining room table
looks after people have been dumping papers and books on it for a week.

How would you program a simulation of a control system in Logo?

Best,

Bill P.

[Kent_McClelland2]

From Kent McClelland (970821.1025 CDT)

Bill Powers (970820.1353 MDT) and Wolfgang Zocher (970821.0830 MEZ)
on the Logo computer language

Another person who has had experience with Logo is Lloyd Klinedinst. He
was talking to me about Logo at the recent Durango conference. He said he
has used it frequently in his career in public education. He was asking me
whether I knew how to do PCT modeling in the Logo environment, and since my
last contact with Logo was 25 years ago I couldn't help him much. Maybe
you could. I imagine he would be interested in anything you came up with
that had a PCT angle.

Best regards,

Kent

[Oded_Maler3]

[From Oded Maler (970821.1344 Pacific time)]

My 2 cents: I taught my son Logo when he was around 10. Turtle
graphics is a great tool to see immediate results. You learn
very nice to build procedures and use recursion. Also the graphical
effects of bugs can be insightful. He liked it and got it.
The weak point is that after some time, the more advanced graphics
requires real and deep geometrical thinking. We did some of the
list stuff as well but didn't go beyond that. Then I wanted to move
to procedural languages and had some dillema: on one hand there is a well
known citation of Dijkstra: "being exposed to Basic programming
causes irreversible mental damage". On the other hand, going to Pascal
where you have to declare everything to death, which is a good practice,
is not very thrilling to a young kid. So we did some Basic, but he
preferred the Logo style programming. Moral: if you are first exposed
to functional programming (which is not your (Bill. P.)) case, you will
feel more comfortable with it. On the other hand, when I taught Prolog
to kids who where exposed to preocedural languages they wanted the
programs to "do" something. I think that if you have a good book on
turtle graphics, Logo is the best first choice for kids. You can do
some modest list processing programs (sorting, concatenation,
etc.) for understanding recusion and modularity. I thing there are
functional languages (modern versions of LISP, ML) that have matrices
and all the stuff you love but I am not sure.

Concerning object-orientation, what I hear is that the neatest object
system is that of Java, but personally I still lag behind this technology.
Objects are just generalization of data-types where you define for each
such class its legal interface with the outside world. It is very good
if you develop software which interfaces with other people's modules,
but can be annoying if you want to make a quick and dirty hack in a
program you write yourself and for yourself.

[Bill_Powers1]

[From Bill Powes (970821.1540 MDT)]

Oded Maler (970821.1344 Pacific time)--

My 2 cents: I taught my son Logo when he was around 10. Turtle
graphics is a great tool to see immediate results. You learn
very nice to build procedures and use recursion. Also the graphical
effects of bugs can be insightful. He liked it and got it.
The weak point is that after some time, the more advanced graphics
requires real and deep geometrical thinking.

That's my impression, too: once you get past the easy built-in stuff, it
gets much harder very rapidly.

<On the other hand, going to Pascal

where you have to declare everything to death, which is a good practice,
is not very thrilling to a young kid.

When you can just write "forward 10" I don't think you're learning
programming. The actual operations that create this result were written by
someone else who _could_ program. I don't have anything against programming
in higher-level languages, but I have this prejudice that you don't really
write good programs unless you can imagine the machine-level instructions
that are involved. The huge size of modern applications, I suspect, is due
partly to the fact that the writers aren't aware of what's going on at the
lower levels. Of course kids should start somewhere in the middle of the
abstraction gradient -- I wouldn't hit them with assembler language.

Maybe one approach would be to write a set of canned programs that can be
used in the "forward 10" kind of programming, but deliberately make them
limited in what they can do. Then when the kid says "Gee, I wish I could
make it move in a curve," you can pull the covers off of the procedure,
show them how it works, and show them how they can change it to do what
they want.

Logo is the best first choice for kids. You can do
some modest list processing programs (sorting, concatenation,
etc.) for understanding recusion and modularity.

The hardest part of this is to tell them why they should want to process
lists and understand recursion and modularity, when I don't understand why
myself (well, maybe I understand why modularity is a good thing). I think
you have to have a real passion for lists to want to see EVERYTHING that
way. And I'm not sold on recursion as a general programming technique.

Concerning object-orientation, what I hear is that the neatest object
system is that of Java, but personally I still lag behind this technology.
Objects are just generalization of data-types where you define for each
such class its legal interface with the outside world. It is very good
if you develop software which interfaces with other people's modules,
but can be annoying if you want to make a quick and dirty hack in a
program you write yourself and for yourself.

Right, it has those practical advantages. But my main objection is what you
put together into the package. Why bundle data and procedures together, as
if for any data set there is only a finite set of procedures that apply to
it? I suppose that if you're not trying to simulate real systems that
doesn't matter so much, but in my applications it matters a lot. The
objects in the environment don't come packaged with the "legal" operations
you can apply to them. The whole point of behavioral modeling is that
organisms can apply any operations at all to the same environment. I could
see packaging _properties_ with the objects.

I don't know anything to speak of about Java programming, but just from
what I can see on the Web, it seems to make all the pages look pretty much
alike. I know the advantages for the poor customer who has to use all sorts
of applications, but as a creative tool it seems to be taking us backward.
Of course I had the same complaint about integrated circuits -- why should
I have to try to design circuits by using big pre-organized chunks that
somebody else thought would be useful? When you standardize too much, you
end up with standardized thinking.

Best,

Bill P.

[Oded_Maler3]

[From Oded Maler]

[Bill P.)

   That's my impression, too: once you get past the easy built-in stuff, it
   gets much harder very rapidly.

I think you can spend few months on writing interesting and
still comprehensive Turtle programs.

   When you can just write "forward 10" I don't think you're learning
   programming. The actual operations that create this result were written by
   someone else who _could_ program. I don't have anything against programming
   in higher-level languages, but I have this prejudice that you don't really
   write good programs unless you can imagine the machine-level instructions
   that are involved.

This is your prejudice but there is now way you could (and should) inflict
your grandson with it. I guess your ancestors would not believe it is
possible to plan a trip without thinking about feeding the horse..

   The hardest part of this is to tell them why they should want to process
   lists and understand recursion and modularity, when I don't understand why
   myself (well, maybe I understand why modularity is a good thing). I think
   you have to have a real passion for lists to want to see EVERYTHING that
   way. And I'm not sold on recursion as a general programming technique.

I don't think that at first hearing, for-loops are more intuitive
than recursion. Again, this is your private bias. As a kid it
took me more than a year to really understand what a nested for loop
does. Once you get the head-tail principle, recursion and
list processing becomes a very natural concept.

   Right, it has those practical advantages. But my main objection is what you
   put together into the package. Why bundle data and procedures together, as
   if for any data set there is only a finite set of procedures that apply to
   it? I suppose that if you're not trying to simulate real systems that
   doesn't matter so much, but in my applications it matters a lot. The
   objects in the environment don't come packaged with the "legal" operations
   you can apply to them. The whole point of behavioral modeling is that
   organisms can apply any operations at all to the same environment. I could
   see packaging _properties_ with the objects.

I think here you get into some meta-physical confusion between a programming
formalism to achieve some computation results, and a modeling formalism
that captures some real-world phenomenoa. Numbers are data-types for
which you can apply addition, etc., but not, say concatenation, which
is an operation on strings. You cannot heat a color and you cannot
divide a cow by two. So whenever you define a class of objects in
a program you say which type of operation it admits. That's all.

   I don't know anything to speak of about Java programming, but just from
   what I can see on the Web, it seems to make all the pages look pretty much
   alike. I know the advantages for the poor customer who has to use all sorts
   of applications, but as a creative tool it seems to be taking us backward.
   Of course I had the same complaint about integrated circuits -- why should
   I have to try to design circuits by using big pre-organized chunks that
   somebody else thought would be useful? When you standardize too much, you
   end up with standardized thinking.

With all sympathy the anarchism, objects allow people to develop standard
libraries for many important applications instead of reinventing the
wheel each time.

--Oded

[Bill_Powers1]

[From Bill Powers (970821.1958 MDT)]

From Oded Maler--

I think you can spend few months on writing interesting and
still comprehensive Turtle programs.

I'll see what the grandson thinks.

  When you can just write "forward 10" I don't think you're learning
  programming.

This is your prejudice but there is no way you could (and should) inflict
your grandson with it. I guess your ancestors would not believe it is
possible to plan a trip without thinking about feeding the horse..

I think I'm getting above my comfortable altitude without an oxygen tank.
It's not up to me to tell my grandson, or anyone else, what to be
interested in.

  The hardest part of this is to tell them why they should want to process
  lists and understand recursion and modularity, when I don't understand why
  myself (well, maybe I understand why modularity is a good thing). I think
  you have to have a real passion for lists to want to see EVERYTHING that
  way. And I'm not sold on recursion as a general programming technique.

I don't think that at first hearing, for-loops are more intuitive
than recursion. Again, this is your private bias. As a kid it
took me more than a year to really understand what a nested for loop
does. Once you get the head-tail principle, recursion and
list processing becomes a very natural concept.

Guess I'll just have to learn more about them. Or maybe not -- they're not
high on the priority list just now.

  The
  objects in the environment don't come packaged with the "legal" operations
  you can apply to them. The whole point of behavioral modeling is that
  organisms can apply any operations at all to the same environment. I could
  see packaging _properties_ with the objects.

I think here you get into some meta-physical confusion between a programming
formalism to achieve some computation results, and a modeling formalism
that captures some real-world phenomenoa.

The latter is my only real interest in mathematics and computing. I leave
the other part for those with the talent to follow that road.

With all sympathy the anarchism, objects allow people to develop standard
libraries for many important applications instead of reinventing the
wheel each time.

Sure; I use the Pascal library routines all the time, without worrying
about how they work (except when they're too slow). But I do have some idea
of how they work, which has solved some problems for me. My kind of
programming, however, is mostly one-of-a-kind, and I'm just as likely to
start from scratch as go to the trouble of digging through the archives to
see how I did something the last time. Usually the n-th iteration is
somewhat better than the first, anyway. Each time you reinvent the wheel,
it works a little better.

Best,

Bill P.