[Squeakland] Logo vs. Squeak

[Alan Kay]

Hi Ken --

There are definitely a lot of good ideas in ToonTalk -- and, as you 
know, I've been interested in various kinds of iconic programming for 
many years. I think some nifty combination of iconic and symbolic 
elements (yet to be discovered) will indeed be part of a much better 
authoring system for all.

Your knot example is a good one, but so is the fact that you used 
English to state your case below. I think you would agree that a 
combination of English and pictures and actual manipulatives would be 
even better, just as quite a bit of math is difficult to express only 
in pictures, though pictures and manipulatives are a great way to 
start off.

Cheers,

Alan

At 1:08 PM +0100 8/9/03, Ken Kahn wrote:
>Alan Kay wrote:
>>
>>  Just a pause for a thought here ... Neither the current Squeak syntax
>>  nor the Logo syntaxes are ideal for children and other end users. We
>>  really should be thinking about what improvements in UI should be
>>  made to help them. Andreas Raab has pointed out that the syntax of a
>>  programming language is actually part of its user interface -- and I
>>  think this is a really important observation. If we look at the
>>  difficulties of having children understand (say) parameter passing in
>>  Logo, we should be thinking about how it should look.
>
>I'd like to urge that people consider radical alternatives to textual
>syntaxes. Syntaxes based upon diagrams or pictures have had limited success
>either because they weren't very general or, despite being visual, they were
>too abstract and difficult for children and other end users. But there are
>alternatives to text (even with tiles) and to pictures. My ToonTalk
>(www.toontalk.com) is an example. The equivalent of a Squeak method in
>ToonTalk are the actions you train a robot to take in a game-like animated
>world. Syntax isn't a good way to think about such things. What is the
>syntax of showing someone how to tie a know for example?
>
>Programs in any language are created, composed, edited, debugged, and
>studied (typically by reading the source code). ToonTalk currently excels in
>creation, debugging, and composition and is very weak for editing. And
>rather than study the source of ToonTalk program you can watch it to
>understand what it does. The shortcoming with editing and studying programs
>can perhaps be overcome - e.g. Mikael Kindborg's work on comic strip
>programming (http://www.ida.liu.se/~mikki/comics/index.html).
>
>Another open question is whether a good animated syntax can be found for all
>computation models.
>
>I think the fundamental idea underlying ToonTalk is that programming can be
>made very concrete without giving up any expressive generality. For young
>children this concreteness is especially important. In ToonTalk parameter
>passing isn't difficult - it is just giving boxes full of stuff to birds or
>robots. Even 4 year olds are able to understand and accomplish a lot - see
>Leonel Morgado's thesis-in-progress - e.g.
>http://www2.cs.fau.de/HCC01/proposals/Morgado-paper.pdf
>
>Best,
>
>-ken


--