Richard wrote:
LOGO is likened to be LISP without parenthesis, which
is why it's what
I tell people to play with when they say "what should I tell my kid to
try if he wants to learn programming?". With turtle graphics built
in, it's easy to get sucked into making pictures and forget that
you're learning how to write recursive programs.
I am very interested in this thread since I design computers for
children, with one of the main goals being to get them to learn
programming (more for the side effects of learning how to debug and how
to incrementally arrive at working solutions).
Back in 1983 I designed a 6809 based computer with Logo in ROM. One
issue was the problem domain. Turtle graphics are great, but robotics
and games are even more attractive. Robotics was already being worked on
in the Lego Logo project, so I concentrated on games. Having multiple
concurrent turtles like in Coco Logo would be a good start, and allowing
the turtles to have any shape (in TI99/4A Logo you had sprites which
could change shape, but those were not turtles) would really help. I
also added object orientation, and this feature got used more and more
so I ended up switching to Smalltalk in 1984.
Additionally, I think that interpretive
environment's like LISP or
LOGO are better for experimentation and rapid feedback. Compiling is
great for speed, but not so good for reinforcing immediate positive
feedback.
That is absolutely critical. But one limitation of Logo was that it
wasn't self revealing. I have played with many implementations of the
language and if I don't have written documentation I can't get very far
(specially in implementations based not based on English).
Unfortunately, the children didn't get that documentation. If it was
available at all, the teacher normally kept it to him/herself. Contrast
that with Basic on the Sinclair machines. Every possible command was
printed right there on the keyboard. You could try random things and
learn without a book. But you normally had a book and a few magazines.
Back in the 8 bit era it was hard to do something about this, but in a
modern system all the documentation you could want should be in the
system itself.
One interesting alternative, which I considered for that project, was
the 1978 Super Basic for the Bally Astrocade (a Z80 machine, so we are
back to the start of this thread) which claimed to be self revealing. It
had GOSUB but also allowed you to define your own named functions (it
called them macros). These functions used INPUT to read the values
supplied as arguments at the call site, but if the argument was missing
it would print the associated prompt text and read the value from the
keyboard. And all the built in commands worked just like this, so typing
in a parcial expression would make the computer print out what
additional data it needed. This interpreter was not sold, so a
repackaged version of it was developed and sold as the Datamax UV-1 high
end machines for video artists and the language was renamed to Zgrass.
A side effect of having one Basic command in each key on the Sinclair
machines (to make typing in programs tolerable on the horrible
keyboards) was that the beginner didn't have to worry about syntax
errors. If you typed something and the computer interpreted it as
something else you saw it right away and could fix it before going any
further. By the time you hit ENTER the syntax was ok, though you might
still have logical errors. The free form text entry in Logo made it
easier to make syntax errors, though misspelled names were more likely
to be a problem. A modern alternative for reducing syntax errors is the
use of graphical blocks to represent code, like in Etoys or Scratch (two
systems implemented in Squeak Smalltalk). It helps a lot in the
beginning, though eventually this gets in the way of writing code.
One problem that Logo in general had was that it was seen by everyone
involved as a very limited tool. As you mentioned, the language itself
certainly doesn't lack power. But most implementations were very weak
due to the limited memories. A good interpreter will take up most of
64KB and leave little room for the user's programs. So Logo was used for
small projects in elementary school while Basic and Pascal were used in
high school. And children quickly tire of things they perceive as being
uninteresting to adults or older children. So in my project I put in a
lot of effort to have a professional quality interpreter. The hardware
included a circuit to have a separate 64KB instruction address space
from the 64KB data address space. That allowed the
interpreter to live
in a 32KB EPROM and still have the full 64KB of RAM for user
programs.
-- Jecel