okeefe.r.a.@edxa (01/23/83)
From: RICHARD HPS (on ERCC DEC-10) <okeefe.r.a.@edxa>
--------
In-Reply-To: taylor... Logo, am I missing the boat?
There are several versions of Logo. The version which I gave mild
praise to was Edinburgh Logo, not because I think the others are
no good but because I know nothing about them. In the rest of this
message, therefore, Logo means Edinburgh Logo.
Let's get this straight: I am not a Logo fan. I would much rather
use Lisp. Logo has been progressively simplified over the years
(without any sacrifice of power). It had to be. Early versions based
on MIT Logo were found to confuse even undergraduate students. I am
critical of many aspects of Edinbrugh Logo, because I think it can be
simplified still further.
Let's get some things straight about BASIC. BASIC was the first
interactive programming language to be designed for use by people
without a maths/engineering background. One of the highlights of
Dartmouth BASIC was graphics, lost by most later BASICs but
recovered (incompatibly) on micros. The designers of BASIC put a
lot of effort into presenting one coherent interface to the user.
Unfortunately, the language they used as a model was FORTRAN. Since
then, we have learned a lot about programming, which has not had any
effect on BASIC. (Most Basics. I'm rather fond of Basic-Plus.)
ANSI standard Basic is a pretty minimal language; there are macro
assemblers with more power. There is a BASIC for every micro, and
often several. Trouble is, they are wildly different. There isn't
even agreement on how you punctuate a line with more than one statement.
(I have seen colon, backslash, and diamond used as statement separators.)
My attitude to BASIC is like the Listerine ad: "I hate it. Twice a day."
The most visible thing about Logo is turtle graphics. There is no reason
why Basic couldn't have it too. {Some do. Most use Cartesian graphics
and you have to know that the screen is 253 x 765 or some other magic
numbers.} Smalltalk and FigForth do have it.
However, the REAL advantage of Logo over Basic is that Logo is based
solidly on the idea that programs are built by combining other programs.
The ability to break a problem into parts, solve the parts, and then put
the parts together again is one of the things that Logo is supposed to teach.
Easily defined procedures (recursive if you want them) are crucial to this.
Some Basics have multi-statement DEF FNs. The only snag there is that they
force an irrelevant linear order into the program by insisting that all the
lines in the program be numbered in one sequence, including DEF FNs.
Turtle graphics? Decent procedures? Sounds like UCSD Pascal! Indeed it
does, but another thing that Logo is supposed to teach is debugging as a
way of thinking. {You may or may not agree. I'm not saying here that Logo
is *better* than Pascal. Just that it's *different*.} If there is a bug in
one procedure, you edit it on the spot (like BASIC; BASIC has a lot of good
ideas) and just keep running; no painful waiting for the UCSD compiler, and
the switch is just command->editor->command context, not command->program->
command->editor->command->compiler->command->program context.
Turtle graphics? Decent procedures? BASIC-like editing? (Edinburgh Logo
has a simple built-in screen editor.) Sounds like a really good Basic!
BASIC provides numbers, strings, and arrays. Logo provides numbers, words,
and lists. ("words" are exactly Lisp "atoms".) Horrors! Lists are SO
wasteful of storage, everyone knows that! Sorry, it isn't true. Using
CDR coding, a list with N elements need only take 2(N+1) bytes. {Logo has
no RplacD operation. It does have a RplacA analogue which makes lists look
like arrays.} A list of N characters (a "string") does need twice as much
storage as in BASIC, but children's programs rarely do any string hacking.
Lists are better data structures for *some* applications than arrays, but
not all. There is no particular reason why Logo couldn't have arrays as
well, or Basic couldn't have lists. But still, garbage collection (scream,
faint)! Garbage collection on a TERAK takes less time than reading a small
file. (Sorry, I don't have any exact figures. If anyone is really interested,
I could ask.)
The final difference between Logo and Basic is the syntax. Logo is pure
forward Polish (Lisp without parentheses) with no infix operations at all.
{Some Logos are different. Edinburgh learned the value of complete
consistency the hard way. Hard on the children, that is.} In particular,
Logo is intelligible to children who have not yet learned how to cope with
mathematical notation {it takes years for most children to be really happy
with 12x(y+z)-2x^2 and some never make it}. All commands and functions
are English words (yes, we remember English in Edinburgh for all that we're
in Scotland). Wherever possible, they are single familiar words. What is
more, Logo makes a syntactic difference between Lvalues and Rvalues. In
make 'width times :width 2
'width is the name of a variable and :width is its value; in
let w3 = w3+1
w3 means different things on different sides of the "=". {Come to that,
so does "=" itself. For a child struggling to come to terms with maths,
the use of "=" as replacement is as helpful as instruction in Basque.
Back when "_" was a left arrow, some Basics used that. Good thinking.}
Dave Taylor says he wants a language which is interpretive, perhaps with
a compilation option, and reasonably mnemonic. Logo is such a language,
except that there is as yet no compiler. {Since a procedure is stored as
a list of lists of tokens, at least there is no reparsing overhead. Logo
can be interpreted nearly as fast as threaded code, which it resembles.}
A complete list of all the system commands and functions takes one side of
an A4 sheet of paper, with lots of empty space and helpful headings.
{I know many Basics can boast the same. Basic could be a lot worse.}
As for Logo being a great language for children, there is a lot of evidence
that it is. The Edinburgh approach is that Logo is a TOOL to be integrated
into the normal syllabus. A very great deal of effort has been put into
the course material, and the people who actually take Logo into the classroom
are qualified teachers. The results over a number of years are that children
exposed to Logo do in fact master it, to the point where they can correctly
explain ALL the constructs in the language, feel that they are in control of
the machine, are better able to discuss their math/programming difficulties
than children in control groups (though there isn't any real evidence that
they are any better at *solving* them), and learn no less mathematics.
I am not aware of any studies using Basic, so I can't say that Basic couldn't
yield these results. But I can say that Logo does.
As for Basic being a good first language for anyone, I have my doubts.
See "Youthful Indiscretions, or Is Basic Bad for your Health?" in
Software Practice & Experience, and the follow-up. Most of the non-CS
people I know whose first language was Fortran have never mastered *it*,
let alone any other. Basic is so similar that something should follow.
On the other hand, Fortran was *my* first language...
About English being a good language for communicating with computers. I
have the advantage of having used three different "Natural Language"
"English" front ends. Natural Language Comprehension is a long way off
yet. There are some pretty impressive demonstrations, but all they are is
pretty, and impressive, and demonstrations. At least Logo and Basic can
be summarised on one sheet of paper. Then again, I haven't the least
desire to talk to a computer in American, and you, e hoa, don't want to
use my dialect. I have taken the following from "Artificial Intelligence
Meets Natural Stupidity", Drew McDermott, SIGART newletter #57:
Language is only occasionally a medium of communication of
information; even when it is, the ratio of information to
packaging is low. The problem of a language speaker is to get
the directed attention of an unprepared listener and slide some
information into his mind in a very short time. Since the major
time sink is moving his mouth, the language sacrifices everything
to brevity; forcing the hearer to do much quick thinking to
compensate. Furthermore, since the speaker doesn't quite know
the organisation of his hearer's mind, his phrasing of information
and packaging must, except for the most stereotyped conversations,
be an artwork of suggestiveness and insight.
In general, except for describing a minor variation on a presolved task
using a previously standardised vocabulary, English is an unbelievably
clumsy programming language. I don't much care for Pascal, but it comes
a lot closer to the way I think about programs than English, so I can
communicate my ideas about programs much more effectively to machines
AND TO PEOPLE in Pascal than I can in English. Clearly, as work in AI/CS
proceeds, this stands a good chance of changing, but I doubt whether
formal languages will ever lack a role. In the meantime, how about COBOL?
That looks a lot like English (it says right here in the manual) and is
available on a lot of micros!
And now for the question which makes all this relevant to info-micro.
What do we want in a programming language for micros? Here's my list
of criteria (some of the omissions are deliberate):
1) The language should not be biassed towards any national language.
The Third World is buying micros, don't forget. This doesn't rule
out the use of a few keywords, provided there is a pre-processor
distributed with the system which will adapt the system to a different
set of words. Languages modelled too closely on English contribute
to the development of an English-speaking technical elite. If the
local Census officer can't understand the system messages, he has
been defrauded. If his supervisor can't hire someone to fix the
program, HE has been defrauded.
2) The language should be simple.
This rules out BASIC and PASCAL. It even rules out a number of Logo
dialects. It even rules out Algol 68, one of my favourite languages.
{This lends my criteria a show of objectivity.} Lisp might sneak by.
It certainly rules out (syntactically) extensible languages, though
Forth and MINT might be acceptable.
3) The language should be command-oriented.
This rules out Prolog, Hope, ML, and Backus FP systems, as all of
them are oriented towards computing values. However, the greatest
virtue of micros (in my opinion) is that you can use them to DO
things. E.g. a micro can monitor field moisture and control an
irrigation system. I am extremely fond of applicative languages,
and have never programmed a real-time application. But I think that
applicative languages reflect a mainframe bias.
4) The language should support problem decomposition.
This means a superb procedure/module facility and an equally good
type/abstraction. Ada approaches this, but it is much too
complicated (= I don't understand all of it yet). CLU is good.
5) Explicit compilation is part of the problem not the solution.
There is a whole gamut of implementation techniques, from compilation
to threaded code to text interpretaiton to tree interpretation to
throw-away compilation. However, nobody ever wants to compile a program.
They want to RUN it, or CHECK it, or make it go faster, or put it in a
library where other people can use it. There are plenty of APL systems,
for example, that compile a function when you finish editing it, and you
have no way of telling.
6) There should be a "reference standard" implementation.
Portability is very important. One of the great things about the
Software Tools package is that (after preprocessing) it is highly
portable. The only reason why I would ever consider using UCSD
pascal for something would be portability. A good clear manual
is important too, but an implementation you can get running fast
is the only known way of *achieving* portability.
Logo doesn't meet criterion (6), and doesn't go as far towards meeting
(4) as it might. Smalltalk meets all of them (the Smalltalk compiler
is said to produce byte-codes, and there is a definition of what the
byte-codes mean) but I doubt whether it could run on an 8-bit micro.
Modula-2 meets criteria (3,4,6). Anyone out there using Modula-2 on
a micro? Basic meets only criteria (3,5), and some Basics with compilation
do not meet criterion 5. Forth and MINT (once known as Snibbol) don't
really support data abstraction. In short, I cannot at the moment recall
any existing language meeting all these criteria that runs on micros.
--------