About the new syntax

Alan Kay Alan.Kay at disney.com
Thu Jun 8 16:56:11 UTC 2000


Stephan --

I should probably say a little about the rationale behind this experiment.

First, it is not aimed at professional and/or expert programmers. Nor does
it try to do "more than" or "better than" the existing syntax.

Here are some of the reasons we are experimenting.

First, it reflects some of the experience from many thousands of hours
working with some thousands of children over the years. The syntax and UI
conventions in the "scriptor" (or "eToy") tiling system are drawn from
solutions to some of the difficulties we've seen.
     Just as an example: For 6-10 year old children especially -- which are
the ones we are most interested in at present, it really makes a difference
when a control structure is prefixed and otherwise specially marked, e.g.
the "Test" conditional frame in etoys.
     Another example: whether you have "Set" or not as a prefix is not
nearly as important, and could be discarded (it is not used in the etoy
system at present).
     I should also mention in passing here that the most recent experiments
this Spring also seem to overwhelmingly confirm the speed and depth of the
children's learning as being partially dependent on the elimination of
typing by hand in the etoy system. The children try many more experiments
and stay with their systems longer, and part of this seems to be the nice
DnD UI of tiles that Dan did.
     We have also been happily collaborating with Randy Pausch's "Alice"
project at CMU for the last several years, and they have done a lot of work
over the last decade or so studying slightly older but still novice users
that they would like to motivate to learn how to do real and exciting
things with a computer. (E.g. see Matt Conway's U of Va thesis of a few
years ago on the design of the first Alice scripting system.)

Second, my particular interest in all this over the last 32 years has been
about finding a route to a new kind of literacy that is an analogy to the
use of print literacy and structured writing (including math) to capture
discussions, presentations, and arguments about important "powerful" ideas.
So I'm much more interested in how the "non-pre-wired-for-math" (both
children and adults) respond to a new representation system than I am in
how the "prewired" do.
     To be really simplistic, it's the first impression that really makes a
difference for most people. Once we grant that we should have some great
examples ...
         (and we do with the etoys -- especially as done by a class of 5th
graders
        this year -- we just haven't quite got them out to the Squeak list yet
         -- look for them this summer),
then after the examples, we have to start asking questions about whether
the system "seems to beckon" or "seems to threaten". And we have to deal
with the approximately 7+-2 "chunks" that the human mind is able to deal
with.
     I believe this is where a little (not a lot of) "syntactic sugaring"
(as Landin used to call it) really works. An example of this in Squeak that
is quite telling (to me at least) is that UI menu items are both (a)
generally made to be readable, and (b) for that reason, are almost never
cast in Squeak syntax. Suppose we improved the UI in many ways and also
decided to use ST-80 syntax in the menus, then imagine the shock to many
first time users of having to understand Squeak conventions just to use the
UI.
     (Naysayers should contemplate that the current ST80 syntax IS a
sugaring of LISP style "really minimalistic" syntax, so what you are used
to already has had some structure and thought put on it.)

    Now, I should confess that I have thought for many years that menu
items SHOULD generally be actual statements in the programming language,
because of the beautiful bridging that is possible. In fact, I would like
to derive object-specific menus as filterings of their class interface ....
This was done once at PARC as one of the first uses of MVC, and was quite
compelling (again, to me at least).
     To me this means that a "language for most" should be as much for
READING as it is for WRITING. (I should also say here that I don't like
trying to imitate a natural language very closely because of the wrong
expectations that are generated. Learning programming is not mainly about
learning a good syntax.)
     But learning programming is partially about the UI for it, and as
Andreas Raab has pointed out, the syntax of the language is definitely part
of the UI, and should be treated with the same respect that eventually has
to be given to the UI.
     So the search for a workable compromise begins once again...

In this particular experiment, we are trying to set up the Squeak world so
we can give the children the next steps beyond the etoys. It is a lot of
work to maintain the etoys as a totally separate case, and so we decided
that it would be interesting to be able to cast all of Squeak in a syntax
similar to the etoys, and to do it in such a way that it doesn't force
anyone who likes the old syntax to make a choice. This way we could then
make the etoys one filtering of the entire system, and could experiment
with other filterings for further stages with relative ease.

Some of the Squeak list may remember the 60s idea of an "operator syntax",
a generalization of unary and binary operators to include "if ... then
...", etc. More recently, Joe Goguen has used this idea very nicely in his
various OBJ systems (algebraic interfaces for objects) and generalized it.
It provided a way to rationalize a few more constructions than the current
ST-80 syntax, but without having to introduce new principles in the
semantics. Here is an example of a simple structuring in the current
release:
     Try differentiating three kinds of structures: Prefix operator
structures, infix-distributed keywords, and everything else. For example,
you could bold the first two categories but use two different shades of
light gray instead of black to distinguish them. See what you think, and
think about what a novice sees. What would happen if we then unagglutinated
the agglutinated keywords? The shade of gray marks them as being together,
the spaces (or whatever) between them makes them more readable (as in a
menu ....).

Dan was a "really good guy" to make this alternative, since he was the
inventor of the current syntax (and still really likes it, and does not
plan to change it).
     But we are after bigger game here than people who happen to like
Smalltalk (and its current syntax). We want "the next 80%" of the
population to feel that a universal scripting system is "beckoning to them"
instead of being "programming for someone else".
    To me, it's not so much a question of the learning effort that
eventually has to be done to learn this new kind of math -- a better syntax
doesn't help much here -- it's getting people started and motivating them
to make the effort -- an unfrightening syntax can make all the difference
here.


Cheers,

Alan

------

At 5:01 AM -0800 6/8/00, Stephane Ducasse wrote:
>Hi Dan
>
>Did Kim tried the new syntax with kids?
>
>It would be good to evaluate (two groups one we the normal and one with new)
>if the new syntax is better.
>
>What is the process that you are planning to put in place to evaluate the
>effectivness of the new syntax?
>
>Only how we react or also kids?
>
>>From the experience we have with kids here. They do not have any problems
>with the old syntax.
>
>We only presented:
>	| caro length|
>	caro _ Turtle new.
>	length _ 10
>	caro trace.
>	caro go: 100.
>	100 timesRepeat: [ caro turnLeft: 45.
>			 caro go: length.
>			 length _ length + 10].
>
>	+ self in method
>
>with all the underlying concepts (except class).
>	We did not introduce (), cascade, block argument yet.
>
>And they could write programs and debug themselves (for the syntactic)
>
>Stef
>
>
>
>
>Stephane DUCASSE (ducasse at iam.unibe.ch) http://www.iam.unibe.ch/~ducasse/
>"if you knew today was your last day on earth, what would you do
>different? ... especially if, by doing something different, today
>might not be your last day on earth" Calvin&Hobbes
>
>University of Bern, Institut fuer informatik and Mathematik
>IAM-SCG, 10 neubruckstrasse, CH-3012 Bern, Switzerland.







More information about the Squeak-dev mailing list