From Ken Kahn:

I recall an MIT Logo group meeting in 1977 where Seymour Papert described Logo as an attempt to take the best ideas from computer science and make them accessible to children. Most of those ideas had come from the Lisp programming language. I think this was a wonderful choice when it was made 30 years ago.

Computer science has moved forward and Logo has barely changed. Yes, LCSI Microworlds Logo adds some nice user interface gadgets and a very impoverished way of running programs in parallel. (Concurrent programs can't really synchronize and can only communicate via global variables.) StarLogo does borrow ideas from computer science but its SIMD model of computation is not flexible enough for the wide range of things that kids might want to program computers to do. It is a good thing only when dealing with problems that are naturally "data parallel". Object Logo and Multi Logo were attempts to borrow from computer science object-oriented programming and parallel processing respectively. But they didn't catch on.

Logo was a good attempt at "child engineering" the ideas in Lisp. And more modern Logo implementations have kept up a bit by including menus, buttons, mice, windows, and the like. But here Logo is just trying to catch up with systems like Visual Basic. And both systems pale compared to the ease of use of user interfaces in computer and video games.

During the last 20 years I have tried 4 times to make a new and better programming system for kids that shares Logo's pedagogic/epistimologic/constructivist view. Each time I tried to follow the original design goals of Logo by "child engineering" the best ideas from computer science. First I tried to introduce object-oriented programming (Smalltalk 72 was doing the same thing but was a corporate secret at the time). Then logic programming. Then visual programming.

ToonTalk (www.toontalk.com) is my most recent attempt. It is based upon what I call "animated programming" where a child does all her programming by manipulating concrete objects inside of an animated game-like world. ToonTalk is a general purpose language where a child programs by training robots, giving birds messages to deliver, manipulating boxes, text pads, and number pads, using animated tools, loading trucks and more. The child is a character in this world and can even fly her helicopter to travel between houses or to see an overview of an ongoing computation.

ToonTalk borrows ideas from computer science about how to program with communicating independent processes. Everything happens in parallel in ToonTalk. There are ways of expressing process spawning, communication, synchronization, and termination. It also borrows from demonstrative and visual programming research.

Anecdotal evidence is that kids enjoy ToonTalk and master it relatively quickly. (See www.toontalk.com/English/users.htm) A large pan-European research project just began on the first of the month that will be building what they call "playgrounds" on top of ToonTalk and Logo. (See www.ioe.ac.uk/playground) They plan to do careful studies of kids using both systems. I'm betting the ToonTalk half comes out ahead.

I think Logo is a good thing - it is just that it could be so much more than it is.

Best,

-ken

From Ken Kahn:

I received a reply to my posting from Wen Su (wens@ncct.sps.mot.com) by email and with his permission I am posting his message and my response to it.

Wen Su  wrote:
>Should the new generation learn concurrent programming
>and declarative style programming only, totally skipping
>the "traditional" sequential programming?

>This is a big question. If yes, ToonTalk's approach
>is definitely the way to go, no doubt about it. In my own
>opinion, it is easier for most people to adopt the declarative
>programming style than the concurrent programming style.
>For example, SQL, as used in data base, is declarative.
>It starts to be accepted universally these days. No people
>would say relational data base is slow today; people only
>cares about the "productivity" it has to offer.

This is the big question, I agree. I see value in kids learning many different programming paradigms. Among them are

1. Concurrent object-oriented languages like ToonTalk. 2. Sequential procedural languages like Logo. 3. Declarative or logic programming languages like Prolog. (See Brian Harvey's recent posting. I should maybe clarify that while ToonTalk has borrowed lots of ideas from logic programming, it doesn't have the nice query and running programs backwards ability of Prolog that Brian described.) 4. Data parallelism like StarLogo. 5. Others. Maybe pure functional programming. Or production systems like Stagecast Creator (formerly known as KidSim and Cocoa).

While I think in the ideal world kids should learn all these different ways of thinking about computation, the real world has limited resources. If I had to prioritize these ways of thinking about programming I would stick to the order I listed them above. Others might prefer other orderings. What criteria should we use to decide this? Naturalness? Generality? Scalability? Elegance? Current popularity among professional programmers? Popularity among computer scientists? Another question is which one should be learned first? And which ones have the best chances of being useful for understanding or solving problems in domains other than programming?

>When I read a posting at your web site: "Axiom 1: the more
>you know about C/C++, the less you know about ToonTalk."
>I laugh but can not agree more at this. This reminds me of
>a saying back in those days when C++ and object C were just
>introduced: A person who likes Object C tends to dislike C++,
>and vice versa. I hope the similar thing won't happen for
>Logo and ToonTalk: A person who likes Logo tends to
>dislike ToonTalk, and vice versa. Just a joke here :-)

>Seriously, though, I believe there is a force that is
>working behind this: Most "average" people tend to like what
>they have already known about, even though what they
>have already known about is not as good as the new one.
>If this is true, this works against the acceptance of
>ToonTalk because the constructs in Logo is more familiar
>to most people (esp. to the so-called technology teachers).
>On the other hand, ToonTalk may be more appeal to the
>children. If ToonTalk can be as fun as, say, SNES's Zelda LTP,
>or the Zelda-64 to be released in a week or two, it definitely
>could win the "war." But those technology "old dogs" (maybe
>I am one of them because I am trained to be a C programmer)
>may be in the way and need to find a strategy to make them
>feel home at this new environment.

I agree most people like what they already know. This might mean that teachers won't give ToonTalk the chance it deserves. But as you point out what appeals to children is also important here. Nintendo SNES's Zelda was a source of ideas and inspiration in building ToonTalk. I don't think I've come close to the charm and appeal of that game, but I think I have come closer than any other "educational" software that I know of.

>This is just a thought from a newbie. I am still reading
>the documents about ToonTalk at your web site and may
>decide to order one. My 10-year-old son has been familiar with
>MicroWorlds and I may want him to play with ToonTalk some day.
>Zelda LTP on SNES was his beloved game when he was about 7 (?).
>He is playing so-called RealTime strategy games on PC these days.

>Regards,
>Wen Su

Thanks for your insightful comments.

Best,

-ken kahn

From Ehud Lamm:

"ToonTalk versus Logo". Before saying one more word, I have to admit I didn't check the toontalk site yet. But...

I once thought about doing alittle experiment and writing an article comparing how people "think" with TIM (The Incredible Machine, computer game) and how they think with Logo.

I believe that aisde from all else, one of Logo's greatest strengths is that it is a language.

When I consider the way my thinking changed over the years, I think the most crucial point was grasping the concept of ANGUAGE. This concept, and the intuitive feeling I have of it, helped me in studiying CS and also in thinking about other issues. Logo was one of my first exposures to language. Indeed, a computer language and not a human tongue, but none the
less a language where you have to try to put linear syntax on your ideas. A system in which semantics are tied to syntax.

I also think that being a computer language, Logo helps in giving a good method for structuring algorithms into self contained parts, and building complex strucutures.

I did look for other ideas (and there are many ideas in trying to find a better method for programming a computer, than using a computer language), and was always dissatisfied. I wanted the flexebility, genericity and elegance of Logo.

I think that the great thing about Logo is that it is not really a protective enviroment. It is REAL. You can get infinite loops, you can do harm. You have the real thing under your hands. Kids shouldn't settle for less.

(Note: This is not against ToonTalk, which as I said I know nothing about. Only general comments about computer languages as superior to any other way of teaching kids through computers).

(Second note. This is somehow also connected to the theme of Hands-On Learning. A short piece on this topic can be find in the archive on my web site.)

Ehud Lamm mslamm@mscc.huji.ac.il
http://www2.cybercities.com/e/ehud - Some of the work a MISCologist.

From Ken Kahn:

Ehud Lamm wrote in message ...
>I once thought about doing alittle experiment and writing an article
>comparing how people "think" with TIM (The Incredible Machine, computer
>game) and how they think with Logo.
>
Sounds interesting. I'd read it if you wrote it.

>I believe that aisde from all else, one of Logo's greatest strengths is
>that it is a language.
>
>When I consider the way my thinking changed over the years, I think the
>most crucial point was grasping the concept of LANGUAGE. This concept, and
>the intuitive feeling I have of it, helped me in studiying CS and also in
>thinking about other issues. Logo was one of my first exposures to
>language. Indeed, a computer language and not a human tongue, but none the
>less a language where you have to try to put linear syntax on your ideas.
>A system in which semantics are tied to syntax.
>
Here's maybe where we need some philosophers to jump in. For a while, sign language was not accepted as a proper language - now it is. People talk about the language of film (referring to the syntax of close-ups, cuts, dissolves, etc.). Is ToonTalk really a language? Does it have a syntax, much less a linear one? I'm not sure that language is the best word to describe ToonTalk, but I am sure it shares the nice properties that programming languages have.

>I also think that being a computer language, Logo helps in giving a good
>method for structuring algorithms into self contained parts, and building
>complex strucutures.
>
Ditto for ToonTalk.

>I did look for other ideas (and there are many ideas in trying to find a
>better method for programming a computer, than using a computer language),
>and was always dissatisfied. I wanted the flexebility, genericity and
>elegance of Logo.
>
ToonTalk is flexible and generic. I think it is elegant too.

>I think that the great thing about Logo is that it is not really a
>protective enviroment. It is REAL. You can get infinite loops, you can do
>harm. You have the real thing under your hands. Kids shouldn't settle for
>less.
>
I agree and ToonTalk is real in the same way that Logo is.

Best,

-ken kahn (www.toontalk.com)

From Ehud Lamm:

On Thu, 26 Nov 1998, Ken Kahn wrote:

> Ehud Lamm wrote in message ...
> >I once thought about doing alittle experiment and writing an article
> >comparing how people "think" with TIM (The Incredible Machine, computer
> >game) and how they think with Logo.
> >
> Sounds interesting. I'd read it if you wrote it.

Maybe I'll have the time to write it. If I do - I'll let you know!

>
> >I believe that aisde from all else, one of Logo's greatest strengths is
> >that it is a language.
> >
> >When I consider the way my thinking changed over the years, I think the
> >most crucial point was grasping the concept of LANGUAGE. This concept, and
> >the intuitive feeling I have of it, helped me in studiying CS and also in
> >thinking about other issues. Logo was one of my first exposures to
> >language. Indeed, a computer language and not a human tongue, but none the
> >less a language where you have to try to put linear syntax on your ideas.
> >A system in which semantics are tied to syntax.
> >
> Here's maybe where we need some philosophers to jump in. For a while, sign
> language was not accepted as a proper language - now it is. People talk
> about the language of film (referring to the syntax of close-ups, cuts,
> dissolves, etc.). Is ToonTalk really a language? Does it have a syntax, much
> less a linear one? I'm not sure that language is the best word to describe
> ToonTalk, but I am sure it shares the nice properties that programming
> languages have.

Wll I do tend to see my self more as a philopher than any thing else (even
though my field of work and studies was CS up till now).

I will not try to define what a language is, since this really is a loaded
question. But I do think some remakrs are inorder.

Sign language was considered as a form of of non-verbal, lower than human
communication, until hearing people tried to learn it, and found out it
has the complexities of other languages. See Oliver Sack's book on this,
and if you are interested in more details see Ursula Bellugi (speeling is
wrong here, I am sure. Sorry)

But it is none the less possible to clearly see when the term language is
used litteraly and when it used metaphorically. "The Language of Cinema"
is not the same as "The language used in France". The concepts are not the
same.

What I'd consider important in a programming language is that it have a
clear syntax (even when graphical) AND clear semantics.

I'd also want some of the things we are accustomed to in programming
languages, like support for common control structures (looping, branching,
recursion), and data strctures (list are fine!)

One of the basic features languages have is the ability to build complex
structures from the ground up. You can use word in sentences, sentences in
paragraphs etc etc. In prog. languages you can define procedures and use
them in place of coding them again. I see theis aspect of managing thought
(by defining "concepts") and complexity highly important. I think it one
of the basic things I learned from Logo.

Ehud Lamm     mslamm@mscc.huji.ac.il
http://www2.cybercities.com/e/ehud/     Subscribe to the E-List today! 

From Dale R. Reed:

>I think Logo is a good thing - it is just that it could be so much more than it is.

Ken, I just surfed to your site and ordered ToonTalk.

But I must admit that I(63 year old retired Electromagnetics Engineer) am more interested in creating fractals and knots and moiré patterns and other objects that I see in Mother Nature or imagine. And I don't think I have changed that much on these accounts over the last 50 years.

I keep thinking about drawing knots with Logo just like I used to think about the lightning currents that I was modeling and responsible for protecting against as they redistributed(in frequency and time) through the graphite composite and aluminum horizontal stabilizer of the being designed fly-by-wire 777.  The lightning currents in the past and now the knots and moiré patterns stir my mind during restless nights sleeps.

I do not like games and I do not find Microworlds all that much fun. It was OK when my little grandsonny lived nearby and he used to sit on my lap and we would create imaginary worlds with dogs and trees and moons but he lives two hours drive away now and growing up very quickly so what I want now is an efficient and powerful way of creating my own designs.

Something that will force my mind to pay attention to detail and offers me the capability to create something interesting that Katy and I can enjoy.  MSWLogo works just fine for my purposes.  I bet I am not that much different than many youngsters.

But Ken, I like new things and will give ToonTalk a go.   

Dale --- $ dale-reed@worldnet.att.net  Seattle, Washington U.S.A. $

From Ray Catzel:

I am an avid supporter of MicroWorlds because of the outstanding success I have experienced enriching hundreds of kids over the past number of years.

One of the great advantages of MicroWorlds is its ability to bridge the gap between objects that are meaningful to children and program coding. You can get away with minimal coding for the youngsters and provide very challenging (and more abstract) projects for the older kids.

I took a brief look at toontalk and can't find the ability to migrate smoothly from "giving objects instructions" to coding syntax.

I have no criticism of "old" technology if it is stable and achieves learning objectives. Parallel, smarallel - do you really think the child cares how the programs run in the background.

Have Fun!

Ray Catzel, President, ComputerPals Inc.

Web site: http://www.computerpals.on.ca/~pals

Email: learn@computerpals.on.ca

From Ken Kahn:

RAY CATZEL wrote ...
>One of the great advantages of MicroWorlds is its ability to bridge the gap
>between objects that are meaningful to children and program coding. You can
>get away with minimal coding for the youngsters and provide very challenging
>(and more abstract) projects for the older kids.
>
>I took a brief look at toontalk and can't find the ability to migrate
>smoothly from "giving objects instructions" to coding syntax.
>

I agree one wants software to span a wide range of abilities and ambitions. I believe ToonTalk does this since one can just play with ToonTalk and maybe put together some objects built by others or one can explore serious computer science topics -- e.g. constructing a parallel quick sort program that is laid out so that one can see the overall computation in a meaningful way.

But I don't put much value on "coding syntax". What I do value are the underlying concepts -- variables, recursion, data structures, conditionals, etc. Turns out if you look really hard there is a way of bridging the gap from ToonTalk to coding syntax. ToonTalk can generate a Java applet of whatever you have programmed in ToonTalk. Effort was made so that the generated Java code is readable -- nice variables names, comments, etc. So there is a bridge to textual programming but I don't see it as a vital component of ToonTalk.

>I have no criticism of "old" technology if it is stable and achieves
>learning objectives.
>

And Jim Muller wrote:
>Fascinating statement...but you raise another question. Why does Logo have
>to be "so much more than it is?"

>When you see the magic that Logo can add to a young child's self-literacy,
>what more could you ask for?

I can think of 2 answers:

1. A programming language is something "to think with". Thinking with sequential procedures and global variables is what Logo offers. I've been thinking that way since I learned to program in 1968. But it was wonderful when in 1973 I learned (mostly from an MIT professor named Carl Hewitt) to think in terms of what he called actors -- concurrent objects with message passing. Then in 1980 I learned from Prolog to think of programs declaratively in terms of predicates and theorem proving. Concurrent Prolog and its sucessors taught me to think with both actors and logic together. I won't claim that one way of thinking completely dominates the others. The Logo way of thinking has its place. I just want to wake up the Logo community to the fact there is much more that can be "borrowed" from computer science.

2. In 1994 I read an article by Sharon Yoder in Logo Exchange entitled "Discouraged? ... Don't dispair!". She asked a class of college freshman about their exposure to Logo. A large percentage had been exposed and nearly all reported it as a negative experience. In the 1970s I taught Logo and also saw the results of teaching by others at the MIT Logo group. It was wonderful. It was "magic". My theory of how to reconcile these 2 facts is that kids can get a tremendous amount from learning Logo if taught by a teacher who deeply understands both kids and programming. I think Sharon's informal survey indicates that such teachers are rare.

So how can we give kids the power and magic of programming when such teachers aren't available? By making a software environment where kids can discover and learn programming on their own. ToonTalk, I claim, is such an environment. Kids can learn ToonTalk by exploring a safe self-revealing environment, by working their way through an interactive puzzle game, by watching narrated demos, by getting help from a software agent, and more. [I wrote a chapter in a book that was just published this month on this topic. The book is The Design of Children's Technology, edited by Alison Druin, published by Morgan Kaufmann]. Early indications are that this really works (see www.toontalk.com/English/users.htm).

And Ray wrote:
> Parallel, smarallel - do you really think the child
>cares how the programs run in the background.

I think I have already partly answered this in point #1 above. But parallelism isn't just another tool of thinking, it is also a better way of programming. For example, one of the demos in ToonTalk is the building of a Ping Pong game. I am convinced that the best way to structure programs is as many independent (but communicating and synchronizing) processes. In the Ping Pong example, the ball, the paddle, and the score keeper are each parallel programs. The world around us is running in parallel and trying to model or simulate it sequentially is unnecessarily difficult.

Best,

-ken kahn

From Brian Harvey:

"Ken Kahn" <KenKahn@ToonTalk.com> writes:
>But I don't put much value on "coding syntax". What I do value are the
>underlying concepts -- variables, recursion, data structures, conditionals,
>etc.

I agree with this, at this broad level of abstraction.  The question is what notation (broadly speaking) makes the ideas most accessible.  Something like a conditional can readily be represented pictorially.  Recursion is a little tougher, because (I think) in order to make something self-referential it has to have a name.  The best pictorial version I've seen is Radia Perlman's old "slot machine," in which the procedure names were colors, and were invoked by colored cards.  I find the BBN Function Machines attempt less compelling; you have to notice that a box inside a box has the same name, which is really no better than text.  I'll be interested to see (tomorrow) how TT does it -- the documentation without the real program left me quite confused.

I guess I think text gets a bum rap these days.  We used to have nothing but text, and everyone has overreacted.  Text is still a really expressive medium!  Even for emotions, let alone computer programs.

> Thinking with
>sequential procedures and global variables is what Logo offers.

Hey, no fair, Logo has local variables!  But I do agree that there are other valuable programming paradigms.

From Jim Muller:

>(snip)
>
>I think Logo is a good thing - it is just that it could be so much more than
>it is.
>

Ken ==>

Fascinating statement...but you raise another question. Why does Logo have to be "so much more than it is?"

When you see the magic that Logo can add to a young child's self-literacy, what more could you ask for?

Regards...Jim Muller

Jim Muller THE GREAT LOGO ADVENTURE at http://www.cyberramp.net/~jmul

From Ken Kahn:

Dale R. Reed wrote
>
>Ken, I just surfed to your site and ordered ToonTalk.
> Thanks. I hope you enjoy it.
>
>I do not like games and I do not find Microworlds all that much fun.
>It was OK when my little grandsonny lived nearby and he used to sit on
>my lap and we would create imaginary worlds with dogs and trees and
>moons but he lives two hours drive away now and growing up very
>quickly so what I want now is an efficient and powerful way of
>creating my own designs.
>

I used to enjoy games a lot before I discovered computer programming. Programming is like a game only more challenging and more open-ended. While designing ToonTalk, I found games to be a great source of ideas for how to make things simpler or more fun without watering them down.

>Something that will force my mind to pay attention to detail and
>offers me the capability to create something interesting that Katy and
>I can enjoy.  MSWLogo works just fine for my purposes.  I bet I am not
>that much different than many youngsters.
> I think the ability "to create something interesting" is most important thing about Logo and ToonTalk.

>But Ken, I like new things and will give ToonTalk a go.

That's a good attitude.

Best,

-ken kahn

From Bill Kerr:

Ken, Thanks for your interesting post about ToonTalk. I probably won't have time to have a close look at it for a while but from the way you are describing it I can't see a lot of difference from MicroWorlds or other LCSI products like My Make Believe Castle (for younger kids). When you contrast ToonTalk with Logo you seem to be referring to older (pre-MicroWorlds) versions of Logo.

>1. A programming language is something "to think with". Thinking with
>sequential procedures and global variables is what Logo offers. I've been
>thinking that way since I learned to program in 1968. But it was wonderful
>when in 1973 I learned (mostly from an MIT professor named Carl Hewitt) to
>think in terms of what he called actors -- concurrent objects with message
>passing.

I have read Papert saying similar things, eg. in his 'Epistomological Pluralism' article (with Turkle) -- what you are describing is the philosophy behind MicroWorlds.

Then in 1980 I learned from Prolog to think of programs
>declaratively in terms of predicates and theorem proving. Concurrent Prolog
>and its sucessors taught me to think with both actors and logic together. I
>won't claim that one way of thinking completely dominates the others. The
>Logo way of thinking has its place. I just want to wake up the Logo
>community to the fact there is much more that can be "borrowed" from
>computer science.

the idea of building both logic and intuition into software, catering for a diversity of learning styles, is also a Papert idea (eg. same article) and I think this is part of the MicroWorlds design.

>2. In 1994 I read an article by Sharon Yoder in Logo Exchange entitled
>"Discouraged? ... Don't dispair!". She asked a class of college freshman
>about their exposure to Logo. A large percentage had been exposed and nearly
>all reported it as a negative experience. In the 1970s I taught Logo and
>also saw the results of teaching by others at the MIT Logo group. It was
>wonderful. It was "magic". My theory of how to reconcile these 2 facts is
>that kids can get a tremendous amount from learning Logo if taught by a
>teacher who deeply understands both kids and programming. I think Sharon's
>informal survey indicates that such teachers are rare.

I agree with your analysis here.

>So how can we give kids the power and magic of programming when such
>teachers aren't available? By making a software environment where kids can
>discover and learn programming on their own. ToonTalk, I claim, is such an
>environment. Kids can learn ToonTalk by exploring a safe self-revealing
>environment, by working their way through an interactive puzzle game, by
>watching narrated demos, by getting help from a software agent, and more. [I
>wrote a chapter in a book that was just published this month on this topic.
>The book is The Design of Children's Technology, edited by Alison Druin,
>published by Morgan Kaufmann]. Early indications are that this really works
>(see www.toontalk.com/English/users.htm).

This argument is both true and dangerous IMO. Good constructionist software will be more intuitive for new users (true) but there will always be a place for good teachers to find diverse ways to take the user to a higher level. To suggest this might happen through the software alone is dangerous. (I'd like to chase up your chapter but no time right now). I think a better solution to the dilemma is to improve teacher education courses because the human factor will always be the most important one.

>And Ray wrote:
>> Parallel, smarallel - do you really think the child
>>cares how the programs run in the background.

>
>I think I have already partly answered this in point #1 above. But
>parallelism isn't just another tool of thinking, it is also a better way of
>programming. For example, one of the demos in ToonTalk is the building of a
>Ping Pong game. I am convinced that the best way to structure programs is as
>many independent (but communicating and synchronizing) processes. In the
>Ping Pong example, the ball, the paddle, and the score keeper are each
>parallel programs. The world around us is running in parallel and trying to
>model or simulate it sequentially is unnecessarily difficult.

I think what Ray meant is that MicroWorlds also support parallelism. What you need to show is that TuneTalk somehow does it better, ie. the difference is somehow obvious to the user not just to a sophisticated computer scientist. (although I'd be interested in either explanation personally, ie. an expansion of your earlier very brief explanation).

I'm interested in finding out more about TuneTalk and its educational philosophy. These brief comments might help you address some of the thinking you will find in this newsgroup.

-- Bill Kerr

From Gary S. Stager:

Brian,

I had a powerful experience yesterday trying to use a new "easier" programming environment for kids. Although I was attempting a very simple task, the clumsiness of the interface required me to call an old colleague who works for the company that produces the stuff. The two of us then spent the next hour trying to collaborate on what should have been a 2 minute program because there was no language for communicating about our program. "Connect the blue thingy to the corner of the icon - no not that corner - I said the merge fork..."

One of the powerful ideas of Logo is that it's sharable. I've recently been reminded of its power by a student of mine who teaches little Latino kids in L.A. These 3rd grade limited-English speaking kids are deconstructing projects created by rich NY private middle school kids and programming (or at least feeling sufficiently confident that they can attempt to program) their own videogames. Logo offers kids an environment in which they can create something sharable very early in their use of the software because it allows for multiple approaches to solving a problem.

From Ken Kahn:

Gary S. Stager wrote
>I had a powerful experience yesterday trying to use a new "easier"
>programming environment for kids. Although I was attempting a very simple
>task, the clumsiness of the interface required me to call an old
>colleague who works for the company that produces the stuff. The two of
>us then spent the next hour trying to collaborate on what should have
>been a 2 minute program because there was no language for communicating
>about our program. "Connect the blue thingy to the corner of the icon -
>no not that corner - I said the merge fork..."
>
>One of the powerful ideas of Logo is that it's sharable. ...

Some things like, Logo, are easier to talk about on a telephone or by email. Not surprising since Logo is textual. Other things like the software you were using, ToonTalk, and knots are not so well-suited for purely verbal discussions. Minsky and Papert once tried to "share" knots over a telephone. They found it extremely difficult.

If you and your colleague had a way to link your computers so you both saw the same screen and maybe you both had a mouse cursor for pointing, then talking on the phone might have been very productive.

But sharability isn't the same as being able to talk about them on the phone. Things you make in ToonTalk are sharable - you can even put them in email messages or convert them to Java applets to show anyone with a web browser what you have made. And these things are composable -- a very very important feature. Sequential Logo is composable as well - but I worry how well Microworlds parallel processes compose if communication is via global variables.

Best,

-ken kahn

From luvisi@andru.sonoma.edu:

"Ken Kahn" <KenKahn@ToonTalk.com> writes: [snip]
> If you and your colleague had a way to link your computers so you both saw
> the same screen and maybe you both had a mouse cursor for pointing, then
> talking on the phone might have been very productive.

vnc is such a piece of software... http://www.orl.co.uk/vnc/

and, like most good software, it's Open Source.

andru

From Brian Harvey:

"Bill Kerr" <kerrb@senet.com.au> writes:
> Then in 1980 I learned from Prolog to think of programs
>>declaratively in terms of predicates and theorem proving. Concurrent Prolog
>>and its sucessors taught me to think with both actors and logic together.

>the idea of building both logic and intuition into software, catering for a
>diversity of learning styles, is also a Papert idea (eg. same article) and I
>think this is part of the MicroWorlds design.

This isn't quite fair.  Any programming language requires logical thinking, but Logic Programming is still very different from procedural programming. The shift in thought processes that's required is of the same order (though in a different direction) as the degree to which the massive parallelism in StarLogo is hugely different from traditional programming, and even from the limited parallelism in Microworlds.

Ken's quite right that there's nothing in any flavor of Logo remotely like logic programming.

Bill Kerr wrote
> Thanks for your interesting post about ToonTalk. I probably won't have time
>to have a close look at it for a while but from the way you are describing
>it I can't see a lot of difference from MicroWorlds or other LCSI products
>like My Make Believe Castle (for younger kids). When you contrast ToonTalk
>with Logo you seem to be referring to older (pre-MicroWorlds) versions of
>Logo.
>

From the point of view of a computer scientist there are very big differences. They differ both in syntax and semantics. Logo has a textual syntax. ToonTalk has an animated visual syntax. Logo is a sequential procedural language. ToonTalk is a concurrent object-oriented language.  My Make Believe Castle is a bit more like ToonTalk but it is not a general purpose programming language.

>>1. A programming language is something "to think with". Thinking with
>>sequential procedures and global variables is what Logo offers. I've been
>>thinking that way since I learned to program in 1968. But it was wonderful
>>when in 1973 I learned (mostly from an MIT professor named Carl Hewitt) to
>>think in terms of what he called actors -- concurrent objects with message
>>passing.
>
>I have read Papert saying similar things, eg. in his 'Epistomological
>Pluralism' article (with Turkle) -- what you are describing is the
>philosophy behind MicroWorlds.
> I've learned a lot from Seymour - including this idea. Maybe I'm mistaken, but Microworlds doesn't really change Logo that much. It adds lots of useful user interface gadgets and a very primitive, impoverished notion of parallel processing. I am not aware of any way to synchronize parallel processes in Microworlds. And the only way processes can communicate is via global variables. This is poor modularity and can lead to extremely hard to track down bugs. And in what sense is Microworlds object-oriented?

>
>the idea of building both logic and intuition into software, catering for a
>diversity of learning styles, is also a Papert idea (eg. same article) and I
>think this is part of the MicroWorlds design.
>

Logic/planning and intuition/tinkering are in that article. And I don't question that Microworlds supports both cognitive styles (as does ToonTalk). But that is a different level than what I was trying to get at. I was pointing out there is a role for logic and declarative thinking as a way of EXPRESSING programs, not just designing and building them.

>
>This argument is both true and dangerous IMO. Good constructionist software
>will be more intuitive for new users (true) but there will always be a place
>for good teachers to find diverse ways to take the user to a higher level.
>To suggest this might happen through the software alone is dangerous. (I'd
>like to chase up your chapter but no time right now). I think a better
>solution to the dilemma is to improve teacher education courses because the
>human factor will always be the most important one.
>

I agree to an extent. But I also see ToonTalk working in the home where there is no teacher. Seymour's most recent book "The Connected Family"  also emphasizes the learning that happens at home.

>
>I think what Ray meant is that MicroWorlds also support parallelism. What
>you need to show is that TuneTalk somehow does it better, ie. the difference
>is somehow obvious to the user not just to a sophisticated computer
>scientist. (although I'd be interested in either explanation personally, ie.
>an expansion of your earlier very brief explanation).
>

I touched on the sophisticated computer scientist answer above. I plan to write 1 or 2 page long answer to this soon and will post it when it is ready.

>I'm interested in finding out more about TuneTalk and its educational
>philosophy. These brief comments might help you address some of the thinking
>you will find in this newsgroup.
> Your comments were helpful, thanks.

Best,

-ken kahn

From Bill Kerr:

Brian wrote:
>Ken's quite right that there's nothing in any flavor of Logo remotely like
>logic programming.

I know nothing about Prologo so I stand corrected. My question would be: what is it about ToonTalk  logic that is both obvious and superior to the logic of MicroWorlds? Is this a powerful idea like recursion that ought to be incorporated into educational software and that its exclusion make Logo "old technology"? Or is it something which is mainly of interest to computer scientists but not to a wider audience? My (admittedly subjective) feeling is that the balance between logic and intuition in MicroWorlds is about right.

-- Bill Kerr

From Brian Harvey:

"Bill Kerr" <kerrb@senet.com.au> writes:
>Brian wrote:
>>Ken's quite right that there's nothing in any flavor of Logo remotely like
>>logic programming.
>
>I know nothing about Prologo so I stand corrected. My question would be:
>what is it about ToonTalk  logic that is both obvious and superior to the
>logic of MicroWorlds? Is this a powerful idea like recursion that ought to
>be incorporated into educational software and that its exclusion make Logo
>"old technology"? Or is it something which is mainly of interest to computer
>scientists but not to a wider audience? My (admittedly subjective) feeling
>is that the balance between logic and intuition in MicroWorlds is about
>right.

First of all, forget about that "balance between logic and intuition" business.  Logic programming involves neither more nor less intuition than procedural programming.

In procedural programming, you tell the computer an ALGORITHM it will use to compute the answers you want.  First do this, then do that, etc.

In logic programming, you tell the computer some FACTS that you know, and some RULES that can be used to infer new facts, and then you ask it questions, and it's the computer's job to figure out how to get the answers.

As a classic example, here is a Logo procedure to append two lists:

to append :a :b if empty? :a [output :b] output fput (first :a) (append bf :a :b) end

By contrast, in logic programming you would enter these rules:

(append [] :b) = :b

IF (append :a :b) = :c THEN (append (fput :x :a) :b) = (fput :x :c)

(This isn't really any particular logic language; I'm trying to use Logo vocabulary and notation to avoid making notation an issue.) With these rules, as with a Logo procedure, you can as questions like

What is (append [1 2 3] [4 5])?

but you can also ask questions like

If (append [1 2 3] :x) is [1 2 3 4 5], what is :x?

or even

If (append :x :y) is [1 2 3 4 5], what are :x and :y?

which will give you all six possible answers!  In Logo, you can't "run a procedure backwards" as you can the rules in a logic language.

The way it works is that the inventors of logic programming invented a sort of universal algorithm, a generalization of pattern matching.

Logic programming is a natural fit for data base querying; it's less obvious as a fit for side-effect-laden programming, although many years ago Ken Kahn wrote a turtle graphics package in Prolog, so his current interests have a long history.

Logic programming really is quite a different way of thinking about programming, and it does, I think, stretch the mind usefully, whether or not one is a computer scientist.  Using Prolog as a first language for kids has a pretty long history, not in the US but definitely in England -- Richard Ennals wrote a Prolog-for-kids book, I think some time in the 1970s but all my books are still in cartons so I can't look it up right now.  (I just moved!)

Executive summary:  I don't think Logo is *obsolete*, but I do think that there are more than one good computer tool for kids!

From Bill Kerr:

Brian Harvey wrote:
>Logic programming really is quite a different way of thinking about
>programming, and it does, I think, stretch the mind usefully, whether
>or not one is a computer scientist.  Using Prolog as a first language
>for kids has a pretty long history, not in the US but definitely in
>England -- Richard Ennals wrote a Prolog-for-kids book,

Thanks for your informative response -- it sounds like Prolog might be a good way to give meaning to the concept of reverse engineering.

-- Bill Kerr

From Bill Kerr:

Ken Kahn wrote:
> Maybe I'm mistaken,
>but Microworlds doesn't really change Logo that much. It adds lots of useful
>user interface gadgets and a very primitive, impoverished notion of parallel
>processing. I am not aware of any way to synchronize parallel processes in
>Microworlds.

I think this MicroWorlds procedure (from MW help on waituntil and also done?) does synchronise parallel processes:

to sq-circ
t1, pd launch [repeat 36 [fd 10 rt 10]]
; t1 draws a circle
t2, pd launch [repeat 4 [fd 50 rt 90]]
; t2 draws a square
waituntil [done? [repeat 36 [fd 10 rt 10]]]
; the procedure does not continue until the circle is finished
; so that the drawings of circles and square are synchronised
t1, pu rt random 360 fd random 50
t2, pu rt random 360 fd random 50
; repositions turtles for next drawing
sq-circ
end

>And the only way processes can communicate is via global
>variables. This is poor modularity and can lead to extremely hard to track
>down bugs. And in what sense is Microworlds object-oriented?

MicroWorlds has a turtlesown primitive that enables you to localise things like the speed or reset position of a turtle which is, for instance, simulating a horse. I'll paste in the MW help explanation here, which will give us some sort of starting point for further discussion. I'm not trying to suggest that MW is fully object orientated but code can reside on objects such as colours, turtles, buttons. This gives students an introduction to elementary oops concepts and for young kids I can't see the point in going beyond that. MW and logo has local variables which would be the main thing, wouldn't it? My main impression from doing a little bit of java oops earlier this year is that everything is 10 times harder than in using logo.

<start of paste from MW help>
turtlesown word

Assigns a variable to all the turtles in the current project. This variable can then be set to a specific value for each turtle. This command also creates a new primitive made of the word set followed by the name of the variable (e.g., turtlesown "speed creates a setspeed command as in t1, setspeed 12). There are two ways to get the value of a given turtle variable: you can talk to a turtle and use the variable name to report the value (e.g., t1, show speed displays 12 in this example) or you can use the turtle name followed by 's (e.g., show t1's "speed displays 12).

Use remove to remove a turtle variable. This removes the named variable for all the turtles in the project. After a turtlesown instruction, the value of the variable is set to the empty list (see the first three lines in the example below).
Example:

turtlesown "speed
t1, show speed
(empty list)
t1, setspeed 10
t2, setspeed 20
t3, setspeed 5
t1, show speed
10
show t2's "speed
20
everyone [fd speed]
everyone [forever [fd speed]]

Choose Stop All from the Edit menu.

remove "speed
<end of paste from MW help>

-- Bill Kerr

From Ken Kahn:

Bill Kerr wrote in message <000201be183d$78328100$9cfc98cb@kerrb>...
>Ken Kahn wrote:
>>I am not aware of any way to synchronize parallel processes in Microworlds.
>
>I think this MicroWorlds procedure (from MW help on waituntil and also
>done?) does synchronise parallel processes:
>
>to sq-circ
>t1, pd launch [repeat 36 [fd 10 rt 10]]
>; t1 draws a circle
>t2, pd launch [repeat 4 [fd 50 rt 90]]
>; t2 draws a square
>waituntil [done? [repeat 36 [fd 10 rt 10]]]
>; the procedure does not continue until the circle is finished
>; so that the drawings of circles and square are synchronised
>t1, pu rt random 360 fd random 50
>t2, pu rt random 360 fd random 50
>; repositions turtles for next drawing
>sq-circ
>end
>

I stand corrected, thanks. This is a kind of control flow synchronization since it waits until the processes spawned for t1 and t2 have terminated. Or does "waituntil [done?" wait until all processes have terminated? Does MicroWorlds also have process synchronization based upon data? So, for example, a consumer process of some data waits until the generator has generated it? Note that in general the generator need not have terminated, it may just be reporting back results as it finds them (e.g. a web search engine). ToonTalk only has data synchronization but that is the more general kind of synchronization, since one can set data (in ToonTalk give a bird a token) indicating that the process is just terminating.

By the way, is there a MicroWorlds manual on the web somewhere?

>>And the only way processes can communicate is via global
>>variables. This is poor modularity and can lead to extremely hard to track
>>down bugs. And in what sense is Microworlds object-oriented?
>
>
>MicroWorlds has a turtlesown primitive that enables you to localise things
>like the speed or reset position of a turtle which is, for instance,
>simulating a horse. I'll paste in the MW help explanation here, which will
>give us some sort of starting point for further discussion. I'm not trying
>to suggest that MW is fully object orientated but code can reside on
objects
>such as colours, turtles, buttons. This gives students an introduction to
>elementary oops concepts and for young kids I can't see the point in going
>beyond that. MW and logo has local variables which would be the main thing,
>wouldn't it? My main impression from doing a little bit of java oops
earlier
>this year is that everything is 10 times harder than in using logo.
>
><start of paste from MW help>
>turtlesown word
>
>Assigns a variable to all the turtles in the current project. This variable
>can then be set to a specific value for each turtle. This command also
>creates a new primitive made of the word set followed by the name of the
>variable (e.g., turtlesown "speed creates a setspeed command as in t1,
>setspeed 12).
>There are two ways to get the value of a given turtle variable: you can
talk
>to a turtle and use the variable name to report the value (e.g., t1, show
>speed displays 12 in this example) or you can use the turtle name followed
>by 's (e.g., show t1's "speed displays 12).
>
>Use remove to remove a turtle variable. This removes the named variable for
>all the turtles in the project.
>After a turtlesown instruction, the value of the variable is set to the
>empty list (see the first three lines in the example below).
>Example:
>
>turtlesown "speed
>t1, show speed
> (empty list)
>t1, setspeed 10
>t2, setspeed 20
>t3, setspeed 5
>t1, show speed
>10
>show t2's "speed
>20
>everyone [fd speed]
>everyone [forever [fd speed]]
>
>Choose Stop All from the Edit menu.
>
>remove "speed
><end of paste from MW help>
>

To me, and many others, the essence of the idea of an object is that it joins local data and behavior. You ask a object to move and whether it walks, swims, or flies depends upon the kind of object it is and what "move" methods have been associated with it. "turtlesown" does give objects some local data (but it is odd that every object in the system has the same set of local variables). But behavior is critical. (I don't happen to think inheritance is critical, though it is often quite nice.)

Best,

-ken kahn (www.toontalk.com)

From Bill Kerr:

>By the way, is there a MicroWorlds manual on the web somewhere?

I think you can download a demo copy of MW, with manual, from www.microworlds.com

>To me, and many others, the essence of the idea of an object is that it
>joins local data and behavior. You ask a object to move and whether it
>walks, swims, or flies depends upon the kind of object it is and what
"move"
>methods have been associated with it. "turtlesown" does give objects some
>local data (but it is odd that every object in the system has the same set
>of local variables). But behavior is critical. (I don't happen to think
>inheritance is critical, though it is often quite nice.)

I sort of understand what you are getting at. From my Java course I recall that this is called polymorphism. I'll have to wait until I have some more time for a closer look at ToonTalk to try to evaluate your comments on both data synchronization and aspects
of OOPs that ought to be incorporated into kids software. Thanks for the prompt responses to my queries.

-- Bill Kerr

From Wen Su:

I think that, if my understanding is correct, there is a major difference between MW and TT here. Suppose in the code below, both subprocesses (called Circle and Square) that are launched try to modify a variable owned by the current process (called Parent), in MW, there is no directly built-in mechanism that allows the Parent process to tell which launched process
modifies the variable first, for example. Of course, this can be done by users by other means. The same issue arised in low-level hardware driver code, or when both the interrupt handler code (the code that is triggered to be executed by a hardware interrupt event) and the main line code try to modify the same variable. In TT, the data change requests are sent from
Circle and Square to Parent and the requests are placed in a queue, and the Parent process can tell which data modification request comes in first by means of its built-in message passing method(bird).

This above comment (if correct), does not imply that MW is inferior as far as its education value is concerned, IMHO. Maybe MW developers happen to believe this feature is not that important for children students. Some people (Ken Kahn?) may believe this is very very important ( I think that is the reason why he talked about the "global variable" accessing issue.); some may not.

Regards,
Wen

From Ken Kahn:

Wen provided a good example in MicroWorlds of my point about the dangers of concurrency in languages with shared state (the variable owned by the Parent process in his posting). Thanks.

His question is about how important this issue is. It would not surprise me if many readers of this news group have taught MicroWorlds for years and never seen a kid run across it. Why should we care? One reason is the principle that we shouldn't give kids programming tools that us adults wouldn't use. nother reason is that kids that do get ambitious and may start to explore what kinds of parallel programming they can do in MicroWorlds will run up across these problems. These problems are very hard for professional programmers to detect, track down, and fix. And even worse is that MicroWorlds doesn't give its users the tools to deal with these problems (locks or critical regions, for example).

Best,

-ken kahn (www.toontalk.com)

From Brian Harvey:

"Ken Kahn" <KenKahn@ToonTalk.com> writes:
> And even worse
>is that MicroWorlds doesn't give its users the tools to deal with these
>problems (locks or critical regions, for example).

I don't know what MW does, but StarLogo tries to guarantee correct results without making the user aware of synchronization issues, by, for example, always guaranteeing that in an IF, the test and the first action in the conditional instruction sequence are done atomically.

From Ken Kahn:

Brian Harvey wrote in message <73pgqn$h6$1@agate.berkeley.edu>...

>I don't know what MW does, but StarLogo tries to guarantee correct

>results without making the user aware of synchronization issues, by,

>for example, always guaranteeing that in an IF, the test and the first

>action in the conditional instruction sequence are done atomically.

That probably works fine in a SIMD language like StarLogo. But atomicity is dangerous in general, since it can lead to deadlock. Here, if the conditional test is a procedure call then that procedure may in turn access something that has been locked by this hidden atomicity rule. And then progress stops.

Best,

-ken kahn (www.toontalk.com)

From Tom Woods:

Hello,

To me, textual programming enables students to express their thoughts in ways similar to spoken language. Reading, writing, speaking and listening are necessarily serial. This is not a bad thing.

Although I'm not familiar with ToonTalk, I can imagine visual programming as being akin to other creative visual processes. In the visual arts the presence of a language is undeniable. With it, artists can express rich parallel thoughts through images. Neither is this a bad thing.

I worry about any implication that one form is inferior to another which is the message I got when it was said that Logo is "old technology." Both forms of expression are important. One is not inferior to another -- just different.

For those of you who may remember my much more active presence on the list a couple years ago, hello again. I finished school and wound up in jail. Don't worry, they let me out at the end of the day. I have the wonderfully creative task of starting a school where nothing existed before. One thing I hope to do soon is have my some of my students build computers out of salvaged components and get into programming. Most of the discussions here seem to involve children. Does anyone have any experience using Logo with adult students?

Regards,

Tom Woods

From Ken Kahn:

Tom & Adele Woods wrote

>To me, textual programming enables students to express their thoughts in
>ways similar to spoken language. Reading, writing, speaking and listening
>are necessarily serial. This is not a bad thing.
>
>Although I'm not familiar with ToonTalk, I can imagine visual programming as
>being akin to other creative visual processes. In the visual arts the
>presence of a language is undeniable. With it, artists can express rich
>parallel thoughts through images. Neither is this a bad thing.
>
>I worry about any implication that one form is inferior to another which is
>the message I got when it was said that Logo is "old technology." Both forms
>of expression are important. One is not inferior to another -- just different.
>

I agree, text is good. But as I wrote in another branch of this thread regarding whether some programming paradigms are superior to others -- there is a need to prioritize here. If a teacher is going to teach just one language in a course should it be a visual or textual one? If a parent is buying a programming language for their children, which language is the best first language? In an ideal world I would love to see children learn both kinds of languages. (And also both sequential procedural languages and concurrent object-oriented ones.)

Maybe I should rephrase the question of Logo's obsolescence as "Is Logo still the best as the first programming language children learn?" I don't believe so. I think visual/animated languages are more appealing to children and easier to learn. I think concurrent object-oriented languages provide a more natural and more powerful thinking tool than sequential procedural languages.

If one agrees with me, then the next question is whether Logo is the best second language to learn. I feel less strongly about this issue but wonder whether a child who has mastered ToonTalk might not be ready for Java or Scheme instead.

Best,

-ken kahn

From Brian Harvey:

"Ken Kahn" <KenKahn@ToonTalk.com> writes:
> I think visual/animated languages are more appealing to children
>and easier to learn.

IMHO the best solution to this problem is a hybrid system, in which things that are easily expressed graphically can be, but also, anything can be expressed textually.  Mike Eisenberg's SchemePaint is still the best example of what I mean.  There are the standard paint program point-and-click tools, but you can also write Scheme programs, and in fact you can make new point-and-click tools by implementing them as Scheme programs.

Microworlds is a decent attempt by the Logo community to build something along these lines, although it's far from perfect.  (I am measuring perfection right now only on the issue of the interchangeability of text and graphics interfaces.)

Maybe ToonTalk is, too, since you say that it produces Java code.  If the Java code isn't too convoluted (I haven't yet had a chance to play with it -- I'll try to do that soon!) and if you can use Java code to create new capabilities in the GUI, then I'll be pleased.

Btw, to say that concurrency is "natural" for people raises a lot of questions for me.  Indeed, I believe that if you're simulating a world of independent actors, it feels natural to program them separately. But my CS students certainly don't find natural the synchronization problems that arise if those actors want to share state!

(And finally, you and others have mentioned that different people have different learning styles; part of mine happens to be that I don't really want to make animations, and I'm more likely to want to know how many combinations a Simplex lock has.  I guess I'm weird.  :-)

From Ken Kahn:

Brian Harvey wrote
>IMHO the best solution to this problem is a hybrid system, in which
>things that are easily expressed graphically can be, but also, anything
>can be expressed textually.

I think this is a great research topic. But I worry about the compromises that would be needed to make this work well for a general-purpose programming language. And I also am uncertain about whether hybrids adds some kind of cognitive complexity. On the other hand, it is always a good thing to be able to see or understand the same thing in multiple ways.

>
>Maybe ToonTalk is, too, since you say that it produces Java code.  If
>the Java code isn't too convoluted (I haven't yet had a chance to play
>with it -- I'll try to do that soon!) and if you can use Java code to
>create new capabilities in the GUI, then I'll be pleased.
>

The Java code is readable but not the kind of code one would write from scratch. Making it possible to change the Java code and have that reflected back into ToonTalk is a very difficult problem.

>Btw, to say that concurrency is "natural" for people raises a lot of
>questions for me.  Indeed, I believe that if you're simulating a world
>of independent actors, it feels natural to program them separately.
>But my CS students certainly don't find natural the synchronization
>problems that arise if those actors want to share state!
>

I agree if the sharing of state is "direct" rather than via message passing. That's why I keep complaining about global variables as the only means of communication in MicroWorlds. I'll write a longer essay on this issue soon and post it here.

Best,

-ken kahn

From Brian Harvey:

"Ken Kahn" <KenKahn@ToonTalk.com> writes:
>The Java code is readable but not the kind of code one would write from
>scratch. Making it possible to change the Java code and have that reflected
>back into ToonTalk is a very difficult problem.

I'm not asking for that.  I'm asking to be able to write, in Java, a new gizmo, let's say a different kind of magic wand, or a new menu item, or whatever, and integrate that into the TT world.

From Bob Gorman:

At 11/18/98 05:24 AM -0800, Brian Harvey wrote:
>I guess I think text gets a bum rap these days.  We used to have nothing

>but text, and everyone has overreacted.  Text is still a really expressive medium! 

Even for emotions, let alone computer programs. I whole-heartily agree. We have a left brain, which enjoys text, and a right brain which enjoys pictures. While so many competitive arguments try to prove that their favorite side is "better", I would simply reply, there is nothing with using BOTH! Indeed, I sometimes group people into 4 categories: Right brain dominant, Left brain dominant, Both brain dominant, and of course, neither!

Bob

"To get NEW Answers, you must ask NEW Questions!" - Bob Gorman

From Dale R. Reed:

Bob Gorman wrote:
>We have a left brain, which enjoys text, and a right brain which enjoys pictures.

I enjoy text(poetry, novels) that create pictures in the mind.  For instance I like to read Victor Hugo.

With Logo I can use text to create pictures that are not exactly as I thought they would be.

I can suprise myself.   I like that.    

Dale --- $ dale-reed@worldnet.att.net  Seattle, Washington U.S.A. $

From Ken Kahn:

    Bob Gorman wrote     We have a left brain, which enjoys text, and a right brain which enjoys pictures. While so many competitive arguments try to prove that their favorite side is "better", I would simply reply, there is nothing with using BOTH!

    Some people are called "visual thinkers" because they seem to be good at solving visual problems and they report using visual imagery when thinking. For these people, textual programming languages are difficult. Visual thinkers would probably both prefer visual programming languages and also be more effective in using them than textual languages. Other people seem to prefer text and symbols. Maybe ToonTalk isn't so appropriate for them. A hybrid textual-visual language might satisfy both kinds of thinkers, but it might not. Compromises are needed to make a good hybrid. And hybrids tend to be more complex and much harder to engineer.     I suspect that kids, particularly younger ones, are more visual and less textual/symbolic in their thinking. I know that these categories are crude and overly simplistic but I think they are useful ways of thinking about these issues.     Does anyone know of psychological research on these questions?    

Best,    

ken kahn

From Brian Harvey:

"Ken Kahn" <KenKahn@ToonTalk.com> writes:
> Compromises are needed to make a good hybrid.

No, no!  Compromises make a bad hybrid.  Syntheses are needed for a good one. (I learned this in Marxism class.)  Compromise would be like those old "macro" systems for the Mac that recorded mouse clicks in pixel coordinates.

So for example, take that exchange-two-values thing you did in TT the other night.  Does the corresponding Java code look like pixels, or does it look like the way you'd program an exchange directly in Java?  (Well, I guess it can't, exactly, but I'd settle for exch(a, b) where exch is a procedure you supply that finds a nice vacant part of the screen.)

From Ken Kahn:

Brian Harvey wrote
>No, no!  Compromises make a bad hybrid.  Syntheses are needed for a good
one.
>(I learned this in Marxism class.)  Compromise would be like those old
"macro"
>systems for the Mac that recorded mouse clicks in pixel coordinates.
>
I'll agree with that (despite seldom agreeing with Marxism).

>So for example, take that exchange-two-values thing you did in TT the other
>night.  Does the corresponding Java code look like pixels, or does it look
>like the way you'd program an exchange directly in Java?  (Well, I guess it
>can't, exactly, but I'd settle for exch(a, b) where exch is a procedure you
>supply that finds a nice vacant part of the screen.)

Somewhere inbetween. Here's the untouched automatically generated Java program from having trained a robot to swap 2 numbers if they are out of order. A great project (any grad students out there lurking?) is to build a tool that transform the following Java code into something more normal. My guess is that a good partial evaluator could do the job.

Best,

-ken kahn (www.toontalk.com)

import ap.toontalk.*;
class Robot_P extends TTRobot {
Robot_P(TTNotebook n) {
  notebook = n;
}
public TTObject gets(TTObject given) throws TTException {
  if (!wants.matches(given)) return null;
  // If given a box that matches the box in his thought bubble (called "wants"),
  // this robot will do the following.
  TTObject hand;
  TTObject temp1;
  // pick up what's in the first hole inside his box
  hand = given.pickUp(0);
  // drop it
  temp1 = hand;
  // pick up what's in the third hole inside his box
  hand = given.pickUp(2);
  // drop it on the first hole inside his box
  given.holeGets(0, hand);
  // pick up the last thing he made or found
  hand = temp1;
  // drop it on the third hole inside his box
  given.holeGets(2, hand);
  return this;  // This robot has finished and will see if the box still matches his thoughts and try again.
}
}
public class Applet_P extends TTApplet {
public static void main(String args[]) {
  new TTFrame().begin(new Applet_P());
}
public void initialize() {
  TTNotebook notebook = TT.NOTEBOOK;
  box = new TTBox(3);
  box.setHole(0, new TTInteger(2, '+'));
  box.setHole(1, new TTScale('>'));
  box.setHole(2, new TTInteger(1, '+'));
  // We just made a box with 3 holes. The first hole contains the number 2. The
  // second hole contains a scale tipped to the left. The third hole contains
  // the number 1.
  robot = new Robot_P(notebook);
  TTBox wants1 = new TTBox(3);
  // This robot will only accept a box with 3 holes. The first hole contains
  // any number. The second hole contains a scale tipped to the left. The third
  // hole contains any number.
  wants1.setHole(0, TT.BLANK_NUMBER);
  wants1.setHole(1, new TTScale('>'));
  wants1.setHole(2, TT.BLANK_NUMBER);
  robot.setWants(wants1);
  team = new TTTeam(box, robot);
  setStartingTeam(team);
  displayThis(box);
}
}

From Brian Harvey:

"Ken Kahn" <KenKahn@ToonTalk.com> writes:
>  hand = given.pickUp(0);
>  temp1 = hand;
>  hand = given.pickUp(2);
>  given.holeGets(0, hand);
>  hand = temp1;
>  given.holeGets(2, hand);

Decent!  I'm impressed.  Would it work without "hand"?  I mean, if we changed the Java code to

  temp1 = given.pickUp(0);
  given.holeGets(0, given.pickUp(2));
  given.holeGets(2, temp1);

would it animate in some decent way?  (Imho that would include just having it all happen in a flash -- as long as it doesn't blow up or leave confetti on the screen or something.)

If this sort of thing works, it opens the door for the kind of text-mode programmability that I (following Eisenberg) want.

[Too bad it's Java with all that fluff about Public blah blah... :-)

If only it were Logo, this would be perfect.]

From Ken Kahn:

Brian Harvey wrote
>Decent!  I'm impressed.  Would it work without "hand"?  I mean, if
>we changed the Java code to
>
>  temp1 = given.pickUp(0);
>  given.holeGets(0, given.pickUp(2));
>  given.holeGets(2, temp1);
>
>would it animate in some decent way?  (Imho that would include just
>having it all happen in a flash -- as long as it doesn't blow up or
>leave confetti on the screen or something.)
>
That should work. And a little "peephole optimizer" could probably automatically generate it.

But I should clarify that the Java applet doesn't show ToonTalk programming environment graphics. In this case you don't see the hand when running as an Applet. If, on the other hand, you build a graphical application inside of ToonTalk (e.g. the Ping Pong game example), then those graphics will be transferred to Java.

Best,

-ken kahn (www.toontalk.com)

From Tom Woods:

Ken Kahn wrote:

>I agree, text is good. But as I wrote in another branch of this thread
>regarding whether some programming paradigms are superior to others -- there
>is a need to prioritize here. If a teacher is going to teach just one
>language in a course should it be a visual or textual one?

Part of the key to this issue is the definition of "superior," and that depends on your priorities.

My priorities: 1. Give students rich and varied opportunities to express their thoughts verbally, visually, auditorially, and kinesthetically. 2. Give students opportunities to think about how they think.

Because programming languages are among the things that offer possibilities in these two areas, I'm interested in exploring ways they can be included in students' learning. If I had to ask a question like you did above, I would ask, If a teacher is going to teach just one language, what will best meet the needs of the students?" I like the answer Brian Harvey stated:

>IMHO the best solution to this problem is a hybrid system, in which
>things that are easily expressed graphically can be, but also, anything
>can be expressed textually.

Tom Woods

From Ken Kahn:

Tom & Adele Woods wrote in message <1.5.4.32.19981123051027.006dbdd4@moose.ncia.net>...
>
>My priorities:
>1. Give students rich and varied opportunities to express their thoughts
>verbally, visually, auditorially, and kinesthetically.

I find this a very exciting idea to pursue. In this discussion I have been emphasizing ToonTalk's visual/animated nature. These other sensory modalities are important and I have made steps in that direction. ToonTalk makes heavy use of sound effects. More interestingly, it uses both canned speech and a text-to-speech engine. If you have a force-feedback joystick (these cost about $100 these days), then when you use ToonTalk you feel the vibrations of the helicopter engine, or the wall when you walk into it, or the weight of something in your hand. Within the next 9 months I plan to integrate speech input into ToonTalk.

Maybe it doesn't need to be said to this audience, but these modalities should be available for kids to use in their own creations. For example, ToonTalk not only uses force-feedback but gives kids the option of including force effects in their own programs. Ditto for sound effects and text-to-speech. And speech input when it is done.

I don't claim to have the answers for how to best use and integrate these varied modalities. There is room for basic research, as well as a variety of engineering efforts, to explore these issues.

Best,

-ken kahn (www.toontalk.com)

From Tom Woods:

Wen Su wrote:

>To express their thoughts verbally using computers is still not
>much different than using pencils and papers, as our previous
>generation did.

Very true. The pencil is a "letter quality printer." Nor is visual expression on a computer vastly different from painting or drawing. I wouldn't want to forsake the pencil and brush for a computer. Students would benefit from exposure to all the tools, I feel.

>I hesitate to be a "nay-sayer" here. But although it is very
>good to give students a multimedia construction tool so that
>they can express their thoughts in these new multimedia tools,
>most tools today are still not easy enough to use for youngsters
>(or even for adults.)

Again true... for the pencil and brush as well. Just ask a student if writing is easy. Just try to paint a picture and get it just the way you want.

Tom Woods

From Tom Woods:

Ken Kahn wrote:
> In this discussion I have been
>emphasizing ToonTalk's visual/animated nature. These other sensory
>modalities are important...

NOW you're talkin' When you get the speech working, will you have equivalent text too? That would be extremely beneficial for emerging and early readers who often start by reading words they have written or spoken themselves. You might be on to something big.

Tom Woods

From Bill Kerr:

Ken Kahn wrote:
I agree most people like what they already know. This might mean that teachers won't give ToonTalk the chance it deserves.

and also in another post replying to Tom Woods:

Maybe I should rephrase the question of Logo's obsolescence as "Is Logo still the best as the first programming language children learn?" I don't believe so. I think visual/animated languages are more appealing to children and easier to learn. I think concurrent object-oriented languages provide a more natural and more powerful thinking tool than sequential procedural languages.

---------------------------------

I like the way you have rephrased your challenge to Logo, which makes it more likely I'll get around to looking at ToonTalk, when I get time from writing reports

With regard to teachers giving TT the chance it deserves: this made me think of something in a book on "Learning in Science" by Osborne & Freyberg (it's a book about Childrens Science), which I just looked up to refresh my memory, I quote:

"Ideas lose status as they become less intelligible, plausible and fruitful. Conversely, new ideas increase in status as they become more intelligible, more plausible and more fruitful." (48) [they write more about exactly what they mean by these terms]

Although I have invested a lot of time in MicroWorlds and it rates well on these 3 criteria I think I should have a hard look at your alternative. It would be foolish to think that Logo/MicroWorlds/next evolution will *always* be the  best first language for kids. From other perspectives I see other problems, however:

my perspective: the trial you are organising is a comparison with Superlogo not MicroWorlds (I don't know much about Superlogo)

your perspective (mine too): the actual market for kids programming languages seems to be shrinking, as more sophisticated pre-packed simulations, like sim-life etc. come on stream.

-- Bill Kerr

Ken Kahn then posted an essay on "Logo with parallel processes vs. ToonTalk".

From Brian Harvey:

"Ken Kahn" <KenKahn@ToonTalk.com> writes:
>In the recent discussion about Logo and ToonTalk, one of the issues was
>about concurrency. I promised a longer response to the question about
>whether the parallelism supported by MicroWorlds is as good as what ToonTalk
>offers. Here's my 7 paragraph long answer:

This is really helpful!  Now I think I can articulate where we differ.

>The lack of subroutines in ToonTalk makes it much more feasible to have much
>larger number of processes than conventional programming languages. The
>reason for this is that everyone implements subroutine calls using a data
>structure called a stack. Stacks are a very effective way of implementing
>procedural calls, including recursive calls. The problem is that each
>process needs its own stack. This makes processes somewhat costly. I've
>tested ToonTalk with tens of thousands of houses (i.e. processes). In
>contrast, when I used Java, it stopped working when I had just a couple
>hundred processes.

I don't understand this.  If the processes were doing embedded recursion, so that you really need to keep all the state of all the procedure calls around, then I don't understand how you're avoiding it.  If your complaint is that the Java stack grows on tail calls, then the problem isn't with subroutines, but with inferior language implementations. Use Berkeley Logo instead!  It does correct tail call elimination.

>Conventional languages have shared state. The same variables, data
>structures, and objects can be accessed from different processes (processes
>that share data are often called threads). Sharing state is necessary in
>these languages in order for threads to work together.

Ah, now I see why you keep (incorrectly) saying "global variables" when describing the alleged limitations of Logo.  Your concern is not with the scope of the variables but with the sharing across processes. But (and this is the main point I want to make here) there is another way to harness concurrency without running into synchronization errors: functional programming!  Race conditions are possible only if the various threads are reassigning values to variables.  But there's no need ever to do that.  (In Logo terms, you never need to use MAKE.) When you lump functional programming in with sequential programming, I think you're not really doing justice to the power of procedure calling as a control mechanism. Some computations really lend themselves to the imperative model of programming you describe.  But what about the classic Logo example of English sentence generation?  I think this is best described as a composition of functions.  And even if the arguments to functions are computed concurrently, there is no synchronization problem. Now, in a way, you DO provide for function calling, with the birds and stuff.  But I think that, because you deprecate the idea, your metaphor makes function calling much more complicated than it should be.  I still don't see why every function call should HAVE to be a separate process -- maybe because I don't understand what you're saying about stack space.  Are you saying that separate processes ensure no mutation of shared variables?  Couldn't you achieve the same thing by not allowing robots (procedures, I take it) to mutate things outside of themselves?

From Ken Kahn:

Brian Harvey wrote
>I don't understand this.  If the processes were doing embedded recursion,
>so that you really need to keep all the state of all the procedure calls
>around, then I don't understand how you're avoiding it.  If your
>complaint is that the Java stack grows on tail calls, then the problem
>isn't with subroutines, but with inferior language implementations.
>Use Berkeley Logo instead!  It does correct tail call elimination.
>

I agree that procedural languages should do tail recursion optimization. But I was trying to make another point. ToonTalk could be implemented as a un-ordered collection of process records. A process record is like a stack frame - it contains a pointer to the code (robots in ToonTalk) and an argument vector (a box in ToonTalk). To be fairer to conventional languages, while ToonTalk has very cheap processes, ordinary procedure calls are more costly since they use the heap rather than a stack. But the fact that stacks are not used is why process spawning, suspension, and termination are very cheap operations in ToonTalk.
>
>But (and this is the main point I want to make here) there is another
>way to harness concurrency without running into synchronization errors:
>functional programming!  Race conditions are possible only if the
>various threads are reassigning values to variables.  But there's no
>need ever to do that.  (In Logo terms, you never need to use MAKE.)
>When you lump functional programming in with sequential programming,
>I think you're not really doing justice to the power of procedure
>calling as a control mechanism.
>
>Some computations really lend themselves to the imperative model of
>programming you describe.  But what about the classic Logo example
>of English sentence generation?  I think this is best described as
>a composition of functions.  And even if the arguments to functions
>are computed concurrently, there is no synchronization problem.
>

I agree that in programs without side-effects as in functional programming all my objections and concerns about synchronization disappear. And I agree some nice programs can be written in a pure functional style, e.g. your sentence generator. But (and this is my main point here) there are too many programs that cannot be written as pure functions. The bank account example I gave earlier is one. Or a score keeper in a game. Or most simulations, animations, games, etc. Even programs that do I/O are hard to fit into the pure functional framework.

>Now, in a way, you DO provide for function calling, with the birds
>and stuff.  But I think that, because you deprecate the idea, your
>metaphor makes function calling much more complicated than it
>should be.  I still don't see why every function call should HAVE to
>be a separate process -- maybe because I don't understand what
>you're saying about stack space.  Are you saying that separate processes
>ensure no mutation of shared variables?  Couldn't you achieve the same
>thing by not allowing robots (procedures, I take it) to mutate things
>outside of themselves?

I would rather say I provide a programming technique or pattern of ToonTalk usage that corresponds exactly to function calling. And I admit it is a bit more complicated when all you want to do is function calling. But I claim you want something more general than function calling. Suppose you want to return 2 items? In ToonTalk you just put 2 birds in the box and as the values are computed they are given to the birds and their corresponding nests get filled. Suppose you don't want a single value but a stream of answers. Maybe even an infinite stream (e.g. the Sieve of Erathosthenes prime number generator). Suppose you want to create a network of cooperating agents. And why should one try to force message passing between objects to fit into the framework of function calling?

We may be losing all but the serious programmers and computer scientists on this list, but I think this is a good thread. I'm learning how to be clearer about what I'm doing.

Best,

-ken kahn (www.toontalk.com)

From Brian Harvey:

"Ken Kahn" <KenKahn@ToonTalk.com> writes:
> But the fact that stacks
>are not used is why process spawning, suspension, and termination are very
>cheap operations in ToonTalk.

I still don't get it, I'm afraid; why is a frame on the stack more expensive than a frame on the heap?  Is this some PC-specific thing I don't know about?

>I would rather say I provide a programming technique or pattern of ToonTalk
>usage that corresponds exactly to function calling. And I admit it is a bit
>more complicated when all you want to do is function calling. But I claim
>you want something more general than function calling. Suppose you want to
>return 2 items?

Interesting -- we are having just that argument right now over on comp.lang.scheme; the implementor types have put in multiple return values for efficiency reasons, and the lambda fans hate it.

But I don't want to make you do everything functionally.  What I want is a language that doesn't impose one paradigm on me, but allows me to choose what's best for the problem at hand.  So, it's not that I want you to leave anything out; I want you to make function composition easier, also!

From Ken Kahn:

Brian Harvey wrote
>I still don't get it, I'm afraid; why is a frame on the stack more
>expensive than a frame on the heap? Is this some PC-specific thing
>I don't know about?
>

I'm sorry, I'm not being clear. Let me start again.

In procedural language implementations, when a procedure is called (non-tail recursively) a frame or record is pushed onto a stack. Each thread or process needs its own stack. When a thread suspends all the memory devoted to the stack is tied up until the process resumes and the procedure calls unwind.

In ToonTalk and related languages, the only memory that a process needs is for 2 pointers: to the program (robots) and to the data (box). There is no stack. There is no other state. That is the point I was trying to make.

Because of this 100,000 processes in ToonTalk is feasible. (The default city size only holds 400 houses but the largest size holds about a 250,000 houses.) What is a reasonable upper limit for the number of processes in Logo?

Some reader may wonder why this matters for kids? Massive parallelism has been shown to useful when kids use StarLogo. In ToonTalk we can have parallelism to the same scale as StarLogo but MIMD (multiple instructions multiple data), not the much more limitted SIMD (single instruction multiple data) of StarLogo. ToonTalk enables one to put a few processes behind each pixel on the screen if you want.

>
>But I don't want to make you do everything functionally. What I want
>is a language that doesn't impose one paradigm on me, but allows me
>to choose what's best for the problem at hand. So, it's not that I
>want you to leave anything out; I want you to make function composition
>easier, also!

But your argument about why concurrency is harmless in functional languages doesn't generalize to the multiple paradigm language you are suggesting. If you don't do everything functionally then concurrency is dangerous and complex. Unless you do things the way ToonTalk does.

Best,

-ken kahn

From Brian Harvey:

"Ken Kahn" <KenKahn@ToonTalk.com> writes:
>In procedural language implementations, when a procedure is called (non-tail
>recursively) a frame or record is pushed onto a stack. Each thread or
>process needs its own stack. When a thread suspends all the memory devoted
>to the stack is tied up until the process resumes and the procedure calls
>unwind.
>
>In ToonTalk and related languages, the only memory that a process needs is
>for 2 pointers: to the program (robots) and to the data (box). There is no
>stack. There is no other state. That is the point I was trying to make.

I still don't see the point. If you take a computation that is naturally expressed as ONE PROCESS with 100,000 procedure calls, and instead make it 100,000 processes, each with (in effect) one procedure call, you haven't saved any storage. If Logo would have needed 100,000 procedure calls, it's because there are 100,000 pieces of saved state needed for the computation.
Why does it matter whether those 100,000 frames are on one stack or divided among 100,000 processes?

If you're saying that you can't have 100,000 processes each doing 100,000 procedure calls, then I agree -- but that's not a fair argument. Logo doesn't do that. No language does that.

Maybe I should put it this way: Instead of 100,000 stack frames, you have 100,000 bird nests. (If you're not using birds, then you are doing something that would be a tail call in Logo, and it's not going to grow the stack.)

>But your argument about why concurrency is harmless in functional languages
>doesn't generalize to the multiple paradigm language you are suggesting. If
>you don't do everything functionally then concurrency is dangerous and
>complex. Unless you do things the way ToonTalk does.

That's why I proposed a compromise: Allow a process to mutate only its own private variables. So as long as you avoid mutation you can have shared data.

From Ken Kahn:

Brian Harvey wrote
>I still don't see the point. If you take a computation that is naturally
>expressed as ONE PROCESS with 100,000 procedure calls, and instead make it
>100,000 processes, each with (in effect) one procedure call, you haven't
>saved any storage. If Logo would have needed 100,000 procedure calls, it's
>because there are 100,000 pieces of saved state needed for the computation.
>Why does it matter whether those 100,000 frames are on one stack or
>divided among 100,000 processes?
>
>If you're saying that you can't have 100,000 processes each doing 100,000
>procedure calls, then I agree -- but that's not a fair argument. Logo
>doesn't do that. No language does that.
>
>Maybe I should put it this way: Instead of 100,000 stack frames, you have
>100,000 bird nests. (If you're not using birds, then you are doing
something
>that would be a tail call in Logo, and it's not going to grow the stack.)
>

100,000 houses. Bird nests are only needed if a computation in a house needs to receive data or requests from other houses.

And yes, languages like ToonTalk can have 100,000 processes each doing procedure calls. I just tried to fill a ToonTalk city with 160,000 houses (it started getting too slow and paging too much after 50,000). In every house a robot is working away counting (they needn't be doing the same thing - I'm just lazy). If you want to try it yourself, change the city size to 200 (that is 200x200 blocks where each block holds 4 houses). You can find a remote control for the size of your city in the Options notebook. Then train a robot to get the robot that repeatedly adds 1 and load him in a truck together with a box with a 1 in it. If you are patient enough you can then just let that robot start up the other 159,999 processes but once some of those processes start working that robot won't get a time slice very often. So train another robot to drop copies of the robot you trained into a truck. Wait a few minutes and then start flying around the city visiting houses.

Why would kids want so many processes? Because I think each object should be a process. And I believe that kids think so to. The idea of objects that are "dead" unless they are processing some message from the outside is strange, even if it is the way C++, Java, Object Logo, etc. work.

>
>That's why I proposed a compromise: Allow a process to mutate only its
>own private variables. So as long as you avoid mutation you can have
>shared data.

So are objects private to a process? How do they communicate between processes? Or is it that the instance variables of the objects are private to the process, but object references are global?

Best,

-ken kahn

From Brian Harvey:

"Ken Kahn" <KenKahn@ToonTalk.com> writes:
>And yes, languages like ToonTalk can have 100,000 processes each doing
>procedure calls.

Now I'm really lost. You argued that procedure calling is bad because they require stack frames, whereas processes are good because they don't. I asked, why does it matter whether state information is on a stack or in a heap -- either you need the state information, in which case it doesn't matter where you store it, or you don't need it, in which case it certainly doesn't matter where you don't store it. You were proposing parallelism as an alternative to composition of functions. And I still don't see why parallelism requires less storage than composition of functions.

>So are objects private to a process? How do they communicate between
>processes? Or is it that the instance variables of the objects are private
>to the process, but object references are global?

Data that belongs to an object shouldn't be a problem; the object is in charge of that data, and it ensures the atomicity of requests to use the data, which it can do because it exports the methods to access the data. It's data not belonging to an object that we have to worry about.

From Ken Kahn:

Brian Harvey wrote in message <73ph80$lp$1@agate.berkeley.edu>...
>"Ken Kahn" <KenKahn@ToonTalk.com> writes:
>>And yes, languages like ToonTalk can have 100,000 processes each doing
>>procedure calls.
>
>Now I'm really lost. You argued that procedure calling is bad because
>they require stack frames, whereas processes are good because they don't.
>I asked, why does it matter whether state information is on a stack or
>in a heap -- either you need the state information, in which case it
>doesn't matter where you store it, or you don't need it, in which case
>it certainly doesn't matter where you don't store it. You were proposing
>parallelism as an alternative to composition of functions. And I still
>don't see why parallelism requires less storage than composition of
>functions.
>

One reason for your confusion is that I probably shouldn't have used the
word "procedure calls" above. Maybe repeatedly excuting a block of
instructions might have been a better way to say it. They are not each
executing a procedure that in turn calls any other procedures.

The stack vs. heap issue isn't the main point but let me try to clarify it.
A stack is typically implemented as a block of memory. If the stack grows
too deep, then either a larger block needs to be allocated and the
information needs to be copied over or the another block of memory needs to
be allocated and linked into the original stack. If the heap is used (either
as in ToonTalk or as alternative way of implementing a stack), then there is
nothing corresponding to the unused portion of the block of memory allocated
for a stack. When the number of processes or threads is in the thousands or
hundreds of thousands this can be an important issue. If you expect typical
programs to have tens or hundreds of threads then a stack is a more
efficient data structure than using the heap. My point is that all
sequential languages with threads that I'm aware of are implemented with
stacks. Hence a low limit on the number of processes that are practical.

On the main point, let's consider a program like this. (Excuse me if I make
any syntax mistakes, it has been a very long time since I've written a Logo
program.)

to a
b
c
end

to b
d
e
end

to d
some code that causes this process to suspend
end

Then when d suspends the stack of a -> b -> d needs to be kept until d
finishes.

The equivalent situation in ToonTalk is that b and c are spawned. b causes d
and e to be spawned. d suspends but there is no stack to be saved.

>
>Data that belongs to an object shouldn't be a problem; the object is
>in charge of that data, and it ensures the atomicity of requests to
>use the data, which it can do because it exports the methods to access
>the data. It's data not belonging to an object that we have to worry
about.

This seems very close to what Java does. A method can be declared
"synchronized" so it is atomic. This can easily lead to deadlocks. I don't
know how frequently it will if kids are programming in such a language.

Best,

-ken kahn (www.toontalk.com)

From Brian Harvey:

"Ken Kahn" <KenKahn@ToonTalk.com> writes:
>to a
>b
>c
>end
>
>to b
>d
>e
>end
>
>to d
>some code that causes this process to suspend
>end
>
>Then when d suspends the stack of a -> b -> d needs to be kept until d
>finishes.
>
>The equivalent situation in ToonTalk is that b and c are spawned. b causes d
>and e to be spawned. d suspends but there is no stack to be saved.

If in fact c can't run until it gets a result from b, then instead of a lot
of stack frames you have a lot of waiting spawned threads, which also take
some state. Or, if all your threads really can run concurrently, you have
saved thread state for context switches. In the Logo version there are at
most three stack frames; in the TT version there are three thread frames
(c, d, e).

If the execution is truly parallel, then of course that state won't wait around as long. But unless you're telling me that a thread as *no* state information associated with it, I'm afraid I still don't see where the saving of memory comes in.

Now, perhaps you are using a really bad memory management system in which a large chunk of physical memory has to be located for a stack, whether or not it's used. But that isn't the fault of stacks, or Logo, or composition of functions!

And remember, nobody is arguing against concurrency here. There's no reason why, if the tasks are independent, a Logo program couldn't say

to a
spawn [b]
c
end

or whatever. What you are arguing is that the ability to do procedure calls inevitably leads to storage loss, and I still don't see it.

From Ken Kahn:

Brian Harvey wrote in message <73uosj$e1s$1@agate.berkeley.edu>...
>If the execution is truly parallel, then of course that state won't wait
>around as long. But unless you're telling me that a thread has *no* state
>information associated with it, I'm afraid I still don't see where the
>saving of memory comes in.
>
>Now, perhaps you are using a really bad memory management system in which
>a large chunk of physical memory has to be allocated for a stack, whether
>or not it's used. But that isn't the fault of stacks, or Logo, or
>composition of functions!
>
Implementation arguments are slippery. You seem to be arguing what is possible and I'm arguing what is current practice. When Java died because I had a few hundred threads, I checked news groups and talked to experts who said that is what you should expect. Now maybe the Java implementors didn't do a very good job (and I tried it on more than one Java implementation). But you really can have tens of thousands of threads or processes in ToonTalk. Millions if there wasn't the overhead of the ToonTalk programming environment (i.e. if ToonTalk supported invisible houses that couldn't be entered).

I believe the Java implementation of threads is good and that within their framework it would be too expensive to support thousands of threads. I refer to Java only because I am more familiar with it. I believe that the cost of threads is high in all mainstream languages that have added threads.

>
>or whatever. What you are arguing is that the ability to do procedure
>calls inevitably leads to storage loss, and I still don't see it.

"Inevitably" might be too strong a word. I'm arguing it does in practice.

Best,

-ken kahn (www.toontalk.com)

From Brian Harvey:

"Ken Kahn" <KenKahn@ToonTalk.com> writes:
>I believe the Java implementation of threads is good and that within their
>framework it would be too expensive to support thousands of threads. I refer
>to Java only because I am more familiar with it. I believe that the cost of
>threads is high in all mainstream languages that have added threads.

That may be. What I don't believe is that the reason has to do with procedure stack frames; I can certainly get > 100,000 deep in procedure calls in Logo without trouble. (And of course if it's a tail call, infinitely deep.)

From Ray Catzel:

I have a headache. I have just spent an hour (I thought Ken deserved it for all his hard work at promoting the product) and ended by Uninstalling it from my system (Win98).

With all this talk about special features of parallel processing and many others I really did not comprehend, I am disappointed in the product. If this is intuitive for elementary school kids,  so is anything that you spend lots of time learning how it works.

It is very visual. However, IMHO I don't think kids will have an easier time working out how to operate a "vacuum cleaner" (one of the numerous icons) than learning "copy and paste" concepts in Windows.

I really don't want to waste any more time on this evaluation description. If the others on the list want to evaluate the product I can only reassure them that the software does uninstall.

I hate to submit a critique such as this for a product that Ken has spent so much time on. But I'm only being honest.

Have Fun!

Ray Catzel,
President, ComputerPals Inc.
Web site: http://www.computerpals.on.ca/~pals
Email: learn@computerpals.on.ca

   From Ken Kahn:

RAY CATZEL wrote

    >I hate to submit a critique such as this for a product that Ken has
spent so much time on. But I'm only being honest.

    I'm glad Ray downloaded the trial version and spent an hour evaluating it. And I appreciate an honest evaluation. My opinion is far from objective but

    1. I've collected a large number of messages from beta testers (of all ages) who had praise for ToonTalk. (www.toontalk.com/English/users.htm).

    2. I've been working with a 4th grade class since January 1995. I would say about 80% of the kids get it and like it.

    3. One of my strongest allies, Julian Pixton, was skeptical about ToonTalk until he watched kids use it. He is the manager of the company that is now publishing ToonTalk in Europe, Australia, Africa, and a few other places.

    I have a theory about why kids do fine with ToonTalk, while many adults don't. I borrowed nearly all the user interface ideas from video and computer games. There are no Windows/Mac widgets like menus, mouse cursors, buttons, etc. Adults expecting a conventional interface find it confusing. Kids don't.

    I urge people on this list to try the trial version themselves (www.toontalk.com/English/free.htm). And, if at all possible, watch as a kid tries it.

    Best,

    -ken

From Brett Leach:

RAY CATZEL wrote:

> I have a headache. ...

I have to disagree with this. I downloaded ToonTalk a couple of nights ago. Woke up the next morning and found my son (10) fascinated by TT. No instruction or anything, he just saw the icon on my desktop and decided to check it out. I've watched him do some incredible stuff so far.

From Wen "Wayne" Su:

ToonTalk, IMHO, is okay. The robot is a great idea! However, I have one complaint about it and one suggestion. The problem is that all the objects, such as boxes, and Pumpy, are too large. It often gets annoying where you have to scroll around everywhere to find a particular robot. The suggestion is that there should be a magnifying glass which would allow you to observe what's in the box. When you drop multiple boxes into another box, often some contents are so minuscule you can't read it well. Although you can always pump it up, a magnifier would be more handy. You can use the glass to see what's in it.

-an 11 year old

From Ken Kahn:

Wen "Wayne" Su wrote in message <73fm0u$kj6$1@news-1.news.gte.net>...
ToonTalk, IMHO, is okay. ...

Thanks for your post. And I like your magnifying glass idea. With high resolution graphics it is easier to see small things. (High resolution graphics requires a 30MB file only available on the CD-ROM.) But a magnifying glass would help even then.

Best,

-ken

From Doug Merrill:

This is my initial evaluation of Toontalk and a comparison with Logo. I got to Toontalk and the Logo newsgroup by typing "Computer Programming for Children" into an internet search engine. I have an 8 year old son who spends "too much" time playing computer games. I thought that I might get him interested in writing his own computer games. I have MSWlogo installed and we are working on a quiz game. His idea is to ask the user quiz questions. If the answer is wrong then the fuse on a picture of a bomb will burn down. After a certain number of wrong answers the bomb explodes. We have gotten a good start on making the bomb work.

Some things I really like about Logo are that it is versatile. It looks like you can do anything with it - text, pictures, movies, interaction. The papers at the Logo foundation web site have lots of ideas and sample code, too.

When I first saw the demo version of Toontalk I was very excited. My son loves computers and Legos. I enjoyed and was challenged by the puzzle game. However, in the puzzle game and in free play I ran into some iritating problems.

1. Placing the hand and other objects in the right place is difficult. It is hard to press the button on Dusty. It is difficult to find the right placement of a large text object to put it in a box. Perhaps you (Ken Kahn) can put a red dot on each object to indicate its "hot spot".

2. The floor gets cluttered fast. The window gets filled quickly with notebooks, tools, robots and birds. To get rid of a notebook I have to press F2 to get Dusty (this takes several seconds), then put him down to check his button setting, pick him up to suck up the notebook. Then I have to hope there is nothing important under the notebook that gets sucked up by mistake. It would be nice to be able to point to an object, press the delete key and have it disappear. Also when the robot is done with the toolbox he does not put it back where he got it from (sound like anybody in your house?). I spent some time looking for a bird only to find that the robot had put the toolbox on top of it. A zoom feature would be nice for looking for things. That is easier than panning across the floor, and standing up does not allow you to see objects clearly. Perhaps you could have a toolbar instead of the tool box. A toolbar is out of the way and won't get covered up. The user could right click on the object in the toolbar to get a new copy and left click on the object on the toolbar to make all of those objects in the main screen float up to the top.

3. The puzzle game was excellent for teaching me how to do things. It got very long, however. A couple times Marty said "We're almost done", but we were not. I quit after the section on the clock and started working on my own. But, how much did I miss? What are the upcoming topics? Is it worth my time to go through them? I cannot find answers to these questions. The puzzle game needs a table of contents and a way to jump to a specific section I am interested in. This brings up the whole concept of help. Traditional Windows help has a table of contents and an index (just like a real book). Toontalk does not have this, Logo does. When I am learning a new computer language I want a reference book where I can look up the syntax of what I want to do and get examples that I can cut-and-paste. But there is no cut-and-paste with Toontalk. I have not seen the trading card manual (Is it one card for each character?), but I cannot imagine that the cards would have enough information on them. Would they correspond to a quick reference page?

4. This leads to a serious problem for Toontalk. I cannot edit my program. Several times in the puzzle game I made mistakes - I did things in the wrong order, handed the robot a box with the wrong number of holes. But I had no way to go back and change it. This happened in the Ping-Pong demo. The programmer made the paddle wrong. She/he had to get rid of the bad paddle and create a new one from the beginning. A big advantage of using a text based language is that I can edit and re-use (cut-and-paste) code. An Undo command would be very helpful while I am on the floor creating my program. Better yet - is there someway to edit aminmation based programs? There were several times during the puzzle game where the only way to get out of a mistake was to blow up the whole building and start over. This seems extreme to me. I imagine children would get very frustrated.

I showed Toontalk to my son. He looked at some of the demos and then wanted to write his own program to make the buildings blow up. He had not paid close attention to how it was done in the demo, but he knew it involved a bomb and a truck. He put the bomb in the truck - Marty came to say that was not possible, bomb needed to be in a box. (This was very good - context specific help.) My son put the bomb in a box and the box in the truck. The truck did not move. I told my son that I thought the truck would only move if there was a robot in it. Together we made a program that made continuously exploding buildings. He liked going up in the helicopter and watching the buildings explode. I asked him what he wanted to do next and he asked me if I thought we could make an airport with airplanes taking off from it. I told him I did not think so.

This is a problem. Toontalk looks like Legos, so kids will want to do Lego-like things with it. I don't think Lego-like things are possible - are they? A house is not just a house, it is a metaphor for a computational process. The only way to build a house is to create a process to happen inside it. And I have no choice in what the house looks like. Also, all the action happens inside the houses. If I make a city I want to be able to walk around and see things happening (like SimCity). But all I will be able to see in Toontalk is trucks, birds and explosions (let me know if I am wrong).

I am having a hard time imaging what I can do with Toontalk that would interest me. The Ping-Pong game looks very crude compared to the initial "wow" of the first encounter with Toontalk. How would my son make his quiz game in Toontalk? I tried putting text on the wall of the room - it was clumsy. But then again, Toontalk is an animated programming language, maybe it doesn't do text well. What does it to well? I am the kind of person who needs lots of examples.

On the other hand I was blown away by the 3D examples in MSWLogo. I want to make a sphere with land masses colored on the surface and make a GIF movie of it (the earth) rotating. I wonder how much computer time a movie of, say, 12 frames would take. Now I understand better how computer animation is done and why Hollywood computer animation requires lots of time and memory. Logo makes me imagine things and wonder about things. I can imagine making a Logo airport with my son - make a bitmap of an airport as the background, then turn the turtles into airplanes and program them to fly. It would be 2-dimensional, not as pretty as Toontalk. But is something like that even possible with Toontalk?

From Ken Kahn:

Doug Merrill wrote
>
>When I first saw the demo version of Toontalk I was very excited. My
>son loves computers and Legos. I enjoyed and was challenged by the
>puzzle game. However, in the puzzle game and in free play I ran into
>some iritating problems.
>
>1. Placing the hand and other objects in the right place is difficult.
>It is hard to press the button on Dusty. It is difficult to find the
>right placement of a large text object to put it in a box. Perhaps you
>(Ken Kahn) can put a red dot on each object to indicate its "hot spot".
>
A red spot would work but ToonTalk, like movies, novels, and many video games, relies upon a "suspension of disbelief". So I am wary of adding anything that might interfere with the fantasy of being in this animated world. Selection is indicated in ToonTalk by wiggling. An object "trembles" because it senses it might be picked up, or vacuumed, or whatever. The price of innovation is that users have to learn to notice the wiggling - there are no wide-spread conventions to rely on.

>2. The floor gets cluttered fast. The window gets filled quickly with
>notebooks, tools, robots and birds.

You are right, it does. This is because everything is pretty large. You can use Pumpy to shrink things down (and with the high resolution graphics you can shrink them quite a lot and still use them effectively). ToonTalk will remember what size and position you like for your tools. ToonTalk is meant to work with a wide range of users. Large objects are appropriate for young kids and novices. Older and more experienced users learn how to customize ToonTalk to their liking.

>To get rid of a notebook I have to
>press F2 to get Dusty (this takes several seconds), then put him down to
>check his button setting, pick him up to suck up the notebook. Then I
>have to hope there is nothing important under the notebook that gets
>sucked up by mistake. It would be nice to be able to point to an
>object, press the delete key and have it disappear.

Again, I decided to try to maintain the underlying fantasy. F2 makes a sound so Dusty comes running to you. F2 while Dusty is coming means you are impatient and he gets there instantly. Pressing the delete key might be a nice short cut for F2, F2, space (to turn him on), space (to turn him off). Thanks for the suggestion.

>Also when the robot
>is done with the toolbox he does not put it back where he got it from
>(sound like anybody in your house?). I spent some time looking for a
>bird only to find that the robot had put the toolbox on top of it. A
>zoom feature would be nice for looking for things. That is easier than
>panning across the floor, and standing up does not allow you to see
>objects clearly. Perhaps you could have a toolbar instead of the tool
>box. A toolbar is out of the way and won't get covered up. The user
>could right click on the object in the toolbar to get a new copy and
>left click on the object on the toolbar to make all of those objects in
>the main screen float up to the top.
>

I like the fantasy that the tool box is character that follows you where you go. It also "explains" why things that "live" in the tool box are the same no matter what room you go to. I'll look into the problem of a robot being trained to move the tool box covering things up - it shouldn't. Thanks for reporting it.

>3. The puzzle game was excellent for teaching me how to do things. It
>got very long, however. A couple times Marty said "We're almost done",
>but we were not. I quit after the section on the clock and started
>working on my own. But, how much did I miss? What are the upcoming
>topics? Is it worth my time to go through them? I cannot find answers
>to these questions. The puzzle game needs a table of contents and a way
>to jump to a specific section I am interested in.

A very good suggestion. I'll make a guide to the puzzle section. Thanks.

>This brings up the
>whole concept of help. Traditional Windows help has a table of contents
>and an index (just like a real book).

There is www.toontalk.com/English/doc.htm. You can reach a local copy on your hard disk from the Help button after starting ToonTalk. And Marty can be called to explain anything you are holding or pointing to by pressing F1.

>Toontalk does not have this, Logo
>does. When I am learning a new computer language I want a reference
>book where I can look up the syntax of what I want to do and get
>examples that I can cut-and-paste. But there is no cut-and-paste with
>Toontalk.

There is cut and paste (see the sensor on Page 30 of the sensor notebook). But as you point out below, there is this issue of editing...

>I have not seen the trading card manual (Is it one card for
>each character?), but I cannot imagine that the cards would have enough
>information on them. Would they correspond to a quick reference page?
>
Yes.

>4. This leads to a serious problem for Toontalk. I cannot edit my
>program. Several times in the puzzle game I made mistakes - I did
>things in the wrong order, handed the robot a box with the wrong number
>of holes. But I had no way to go back and change it. This happened in
>the Ping-Pong demo. The programmer made the paddle wrong. She/he had
>to get rid of the bad paddle and create a new one from the beginning. A
>big advantage of using a text based language is that I can edit and
>re-use (cut-and-paste) code. An Undo command would be very helpful
>while I am on the floor creating my program. Better yet - is there
>someway to edit aminmation based programs? There were several times
>during the puzzle game where the only way to get out of a mistake was to
>blow up the whole building and start over. This seems extreme to me. I
>imagine children would get very frustrated.
>

The design and engineering of an editor for an animated language like ToonTalk is a big undertaking. I have plenty of ideas. The only thing implemented is that you can retrain a robot. If you vacuum out the contents of his thought bubble and give him a box, you'll enter his imagination. And the robot will begin to redo what he was trained to do. At any point you can interrupt him and take over. On the average it cuts your work in half.

The funny thing is that I haven't seen kids getting frustrated redoing robots. There are lots of times when kids voluntarily redo something over and over again until they get it right. This is extremely common when playing video games. Kids will try over and over again to beat a "boss" in Super Mario Brothers, for example.

>I asked
>him what he wanted to do next and he asked me if I thought we could make
>an airport with airplanes taking off from it. I told him I did not
>think so.
>
>This is a problem. Toontalk looks like Legos, so kids will want to do
>Lego-like things with it. I don't think Lego-like things are possible -
>are they? A house is not just a house, it is a metaphor for a
>computational process. The only way to build a house is to create a
>process to happen inside it. And I have no choice in what the house
>looks like. Also, all the action happens inside the houses. If I make
>a city I want to be able to walk around and see things happening (like
>SimCity). But all I will be able to see in Toontalk is trucks, birds
>and explosions (let me know if I am wrong).
>

You can add objects to a city and they can have robots on the back giving them a behavior. But the more general answer is to use the same techniques in the Ping Pong example. You can make a combination of pictures with robots on the back giving the pictures any behavior you like. The pictures can be the clip art included in ToonTalk or imported BMP files. You can of course make the picture fill the screen and cover all the ToonTalk object below.

>I am having a hard time imaging what I can do with Toontalk that would
>interest me. The Ping-Pong game looks very crude compared to the
>initial "wow" of the first encounter with Toontalk. How would my son
>make his quiz game in Toontalk? I tried putting text on the wall of the
>room - it was clumsy. But then again, Toontalk is an animated
>programming language, maybe it doesn't do text well. What does it to
>well? I am the kind of person who needs lots of examples.
>

Text-oriented programs are possible, but I concede they are more awkward in ToonTalk. Text can act just like a picture and be combined with other text on a background. Text input is character-by-character (though a word or line based input robot team could be built and put in a library). (The Examples notebook does contain a sentence generator.)

Thanks for taking the time to both try ToonTalk and write a long evaluation. And thanks for your good suggestions.

Best,

-ken kahn

From Ken Kahn:

Wen Su sent a message to the ToonTalk discussion list (toontalk@lists.best.com) where he brought up questions about a sequential ToonTalk. Given the recent discussion here I thought I should re-post his message and my reply. Wen wrote:

>I think I understand that the concurrency feature is at the
>the heart of ToonTalk. But, after reading some postings in Logo
>user's group, I feel it is sometimes difficult, if not impossible,
>for some people to like/accept the idea that there are alternative
>programming models than the traditional step-by-step sequetinal
>programming model, that may be useful under SOME situations.
>When I first learned to program, I myself did not learn
>such concepts that are typically taught in Operating System courses.
>
>For example, if some people are only interested in introducing very simple
>sequential programming concepts to their children, can ToonTalk, with
>some minor change, or "coated" with a thin layer of code (so that the
>concurrency feature, which is just TOO MUCH for them to digest now, is
hidden
>temporarily until they are ready for this), is still useful to these
people?
>
>TT's animation feature is of great helps to beginners even in the pure
>sequential programming context. In a sense, this is "Acting Turtle" but
>in bird's view rather than the first person view. For example, if
>the beginners just want to learn the program sequencing, or
>the "if statement", or loops, we may give them "preprogrammed" robots which
does
>nothing rather than give orders to other robots (via message passing
mechanism, but some
>actions are made invisible if appropriate).
>
>This "highly-simplified, no-brainer" TT may be more like an example TT
program
>rather than the general-purpose programming environment (more or less like
an emulator.)
>
>Games often provides difficulty levels. So should TT, I think.
>
>I do not know this is just my dream that just run wild, or it is feasible
>or desirable to provide such an emulated environment.
>
>--Regards
>Wen

Wen brings up some interesting questions.

One question is could there be a version of ToonTalk that was sequential? One might think it would be a small change - instead of training a robot to drop a box and team of robots into a truck, you train him to give the box to the team. We would then have replaced process spawning by procedure calls. (Well, not quite if you also want to deal with return values from the procedure call. You could also get rid of birds and nests and make a version of ToonTalk where a robot left something behind when he stopped. What he left behind could be the return value.)

Would this sequential ToonTalk be easier to use or understand? Could it do as much as the current ToonTalk? First consider what it would be like to watch a computation as robots get hold of other robots and give them boxes to work on. It could get messy and confusing but maybe one could work out a good way to showing what is happening (something like a stack of waiting
robots). I doubt that it would be easier to understand (unless you already had learned some sequential programming language and expect all other languages to work in a similar way - and most do). Then there is the problem of game or sprite programming. The Ping Pong demo depends critically on the ball, paddle, and score keeper running in parallel - how would such a thing be programmed in a sequential ToonTalk? (Of course, it is possible to simulate parallelism within a sequential ToonTalk but that is messy and confusing.)

I agree with Wen that it is difficult for some people (adults) to like/accept non-sequential programming. And they may prefer teaching kids sequential languages. But I believe kids who have never programmed expect computations to be concurrent. The world around them is concurrent - cars are driving, birds are flying, kids are playing soccer, and so on. They can walk and talk at the same. And forces are concurrent - they toss a ball on a windy day and both gravity and the wind act upon it. What is natural about sequential procedure calls?

Best,

-ken kahn (www.toontalk.com)

From Brian Harvey:

"Ken Kahn" <KenKahn@ToonTalk.com> writes:
>I agree with Wen that it is difficult for some people (adults) to
>like/accept non-sequential programming. And they may prefer teaching kids
>sequential languages. But I believe kids who have never programmed expect
>computations to be concurrent. The world around them is concurrent - cars
>are driving, birds are flying, kids are playing soccer, and so on. They can
>walk and talk at the same. And forces are concurrent - they toss a ball on a
>windy day and both gravity and the wind act upon it. What is natural about
>sequential procedure calls?

My question is, why does it have to be either/or? StarLogo is about as parallel as a language can get, but it still allows composition of functions where that's appropriate.

When kids play games, there are lots of sequential things that happen. First you hit the ball, then you run around the bases. I think this business about sequential VERSUS parallel is a red herring. The question is why you feel the need to throw 3,000 years of mathematics out the window just because you have a new idea -- can't you still remember the old ideas? (Just in case it's not obvious, the 3,000 years are about composition of functions.)

In fact, from my point of view, it's particularly ironic that you use "sequential" as a dirty word, since TT is much *more* sequential than any other programming language I've ever seen, even BASIC. Where I can say
(2+3) * (4+5)
putting my focus on the answer I want, you have to say
pick up a 2
put it in a box
pick up a 3
put it on top of the box
wait a few minutes while they get bammed together
now put that down and pick up another box
pick up a 4
put it in a box
pick up a 5
put it on top of the box
wait a few more minutes
get the 9 out of the box
somehow (I haven't gotten that far yet) put a times sign
in front of it
now pick up the 5 from the 2+3
put it on the X9
wait some more
You call that not sequential?

From Ken Kahn:

Brian Harvey wrote in message <73phsa$218$1@agate.berkeley.edu>...
>
>My question is, why does it have to be either/or? StarLogo is about as
>parallel as a language can get, but it still allows composition of
>functions where that's appropriate.
>
>When kids play games, there are lots of sequential things that happen.
>First you hit the ball, then you run around the bases. I think this
>business about sequential VERSUS parallel is a red herring. The question
>is why you feel the need to throw 3,000 years of mathematics out the
>window just because you have a new idea -- can't you still remember the
>old ideas? (Just in case it's not obvious, the 3,000 years are about
>composition of functions.)
>

I happen to think functional composition is a red herring. It is only a SYNTATIC issue. Consider computing the number of seconds in a day. You can use functional composition and enter an expression like

(* hours_in_a_day (* minutes_in_an_hour seconds_in_a_minute))

or you can avoid functional composition and write

(let ((seconds_in_an_hour (* minutes_in_an_hour seconds_in_a_minute))
(* hours_in_a_day seconds_in_an_hour)
)

I don't see this as a big issue. One could even argue that the second way is a better programming style since you name intermediate results. And logic and relations are at least as old as functions. Functions are just a special case of relations that are many-to-one.

>In fact, from my point of view, it's particularly ironic that you use
>"sequential" as a dirty word, since TT is much *more* sequential than
>any other programming language I've ever seen, even BASIC. Where I can
>say
> (2+3) * (4+5)
>putting my focus on the answer I want, you have to say
> pick up a 2
> put it in a box
> pick up a 3
> put it on top of the box
> wait a few minutes while they get bammed together
> now put that down and pick up another box
> pick up a 4
> put it in a box
> pick up a 5
> put it on top of the box
> wait a few more minutes
> get the 9 out of the box
> somehow (I haven't gotten that far yet) put a times sign

Type x, X, or * while holding the 9.

> in front of it
> now pick up the 5 from the 2+3
> put it on the X9
> wait some more
>You call that not sequential?

Yes, it is expressed sequentially. But this style is only when using primitive operations like arithmetic. (And since pure arithmetic is very easy to parallelize this could run in parallel in principle.) A purist could train a robot to take a box with 2 numbers and bird, combine the numbers appropriately and give the bird the result. You can then program (2+3) * (4+5) by loading up trucks with this robot so it does run in parallel. This is sometimes a better style. It is used in the doubly recursive version of factorial (see www.toontalk.com/English/programs.htm).)

ToonTalk provides an "immediate mode" version of arithmetic because I believe it is easier (and more fun since Bammer the Mouse is popular with kids). But the computer scientist in me thinks I shouldn't have made a special case of arithmetic when it wasn't strictly necessary. Prolog, by the way, also provides a special syntax for arithmetic that isn't strictly necessary.

It is true that you hit the ball before you run around the bases. The design question here is whether you make a more complex language and implementation and support both parallel and sequential executions or not. I chose to keep things simple. So to program this you need to have the part of the program that decides that a ball is hit to give a bird a token indicating that the ball has been hit. The part of the program for running around the bases has to be waiting for that token to arrive before starting. It is not that hard to express things this way.

Best,

-ken kahn (www.toontalk.com)

"Ken Kahn" <KenKahn@ToonTalk.com> writes:
>It is true that you hit the ball before you run around the bases. The design
>question here is whether you make a more complex language and implementation
>and support both parallel and sequential executions or not. I chose to keep
>things simple.

I think this may be the core of our disagreement. It's not quite clear from that sentence whether you mean "simple for the implementor" or "simple for the user." If the former, we disagree in principle. If the latter, we disagree about user interface strategy. I'm not convinced that simplicity means "give the user a hammer and teach him that everything is a nail"!

You started this whole discussion by saying that computer science has moved on since Logo, and we should support new paradigms. So I think it's worth noting that the mainstream languages that support parallelism and OOP haven't thrown out other expressive mechanisms; afaik that's unique to TT.

From Ken Kahn:

Brian Harvey wrote in message <73unos$dlc$1@agate.berkeley.edu>...
>
>I think this may be the core of our disagreement. It's not quite clear
from
>that sentence whether you mean "simple for the implementor" or "simple for
>the user." If the former, we disagree in principle. If the latter, we
>disagree about user interface strategy. I'm not convinced that simplicity
>means "give the user a hammer and teach him that everything is a nail"!
>

I do mean the user. Though I would like advanced users to have a good idea of how things are implemented. Don't Scheme and Lisp courses teach students how to write meta-interpreters? That is a lot harder to do if the language isn't simple.

When I first came to Xerox PARC (1984) I became heavily involved in a multi-paradigm language project (called Loops, then InterLoops, then CommonLoops, and I dropped out when it became CLOS). I recall reviewing a paper written at Bell Labs that argued persuasively that there were very large cognitive and collaborative costs to using such rich languages. I became convinced that it is hard for most people to switch between different programming paradigms at the fine-grain that these languages enable. And the author of the paper reported on the problems teams at Bell Labs had due to different members using very different ways of programming. Team members found it hard to understand and modify each other's code.

Also there can be interference between the parts. A Prolog-like, logic programming, component has troubles integrating well with an imperative sub-language. A pure functional component permits all sorts of program transformations and parallel executions that break when integrated with languages with side-effects.

>You started this whole discussion by saying that computer science has moved
>on since Logo, and we should support new paradigms. So I think it's worth
>noting that the mainstream languages that support parallelism and OOP haven't
>thrown out other expressive mechanisms; afaik that's unique to TT.

Yes, the mainstream has just added parallelism to existing frameworks. And professional programmers have a hard time understanding and debugging Java programs with threads (and Java is one of the better examples of this). Computer scientists continue to explore actor, functional, logic-based, and constraint-based programming languages that, like ToonTalk, throw out some old ideas in order to make progress. In contrast, the computer industry or mainstream just tries to graft new things on the old.

This news group is about Logo - about powerful programming languages for kids. Unlike the mainstream, the constraints of legacy systems and backwards compatibility are minimal. And we can give kids the ability to make parallel programs without forcing them to master the complexity of locks and atomic regions. And without expecting them to debug race conditions and deadlocks.

Best,

-ken kahn (www.toontalk.com)

From Brian Harvey:

"Ken Kahn" <KenKahn@ToonTalk.com> writes:
> I recall reviewing a
>paper written at Bell Labs that argued persausively that there were very
>large cognitive and collaborative costs to using such rich languages. I
>became convinced that it is hard for most people to switch between different
>programming paradigms at the fine-grain that these languages enable.

I guess I'd like to know whether all paradigms are equally hard in this sense. My teaching experience has made me (reluctantly!) conclude that sequential programming is most natural for most people, and that functional programming takes more mental effort (although the effort does pay off dramatically). Where is concurrent programming on that scale? What is the marginal cost of keeping function composition in a language, on that scale, versus the marginal cost of including concurrency?

>Also there can be interference between the parts. A Prolog-like, logic
>programming, component has troubles integrating well with an imperative
>sub-language. A pure functional component permits all sorts of program
>transformations and parallel executions that break when integrated with
>languages with side-effects.

I was with you on the logic programming example, but the functional one seems to me to be a bit of sleight-of-hand; there you are talking about complexity for the implementor, not cognitive load for the user.

>Yes, the mainstream has just added parallelism to existing frameworks. And
>professional programmers have a hard time understanding and debugging Java
>programs with threads (and Java is one of the better examples of this).
>Computer scientists continue to explore actor, functional, logic-based, and
>constraint-based programming languages that, like ToonTalk, throw out some
>old ideas in order to make progress. In contrast, the computer industry or
>mainstream just tries to graft new things on the old.

I'm convinced that it's difficult to debug programs that combine concurrency with mutation of shared variables. I'm not convinced, yet, that you can't have all of
* concurrency
* composition of functions without mutation
* mutation of local (not shared) variables
all in the same language, without trouble.

P.S. In Scheme we can do functional, sequential, concurrent, and OOP, even though Scheme is, in at least one sense, a very simple language. It doesn't have millions of primitives, like CLOS, or a lot of syntax, like Java. We try to teach our students to be able to use several programming paradigms, but to pay attention to which one they're using. I suspect that those programmers you mention who had confusingly mixed styles were handed a Common Lisp manual with no explicit instruction about paradigms at all.

From Ken Kahn:

Brian Harvey wrote in message <73v2ml$lk6$1@agate.berkeley.edu>...
>I guess I'd like to know whether all paradigms are equally hard in this
>sense. My teaching experience has made me (reluctantly!) conclude that
>sequential programming is most natural for most people, and that
>functional programming takes more mental effort (although the effort
>does pay off dramatically). Where is concurrent programming on that
>scale? What is the marginal cost of keeping function composition in
>a language, on that scale, versus the marginal cost of including
>concurrency?
>

Very good questions! Does anyone know of research trying to answer these types of questions? Either in the computers and education literature or the psychology of programming? (The only thing I can think of is Mitch Resnick's masters thesis on MultiLogo.)

>>A pure functional component permits all sorts of program
>>transformations and parallel executions that break when integrated with
>>languages with side-effects.
>
>the functional one
>seems to me to be a bit of sleight-of-hand; there you are talking about
>complexity for the implementor, not cognitive load for the user.
>

How about concern for the order of execution of the arguments to a function? In the pure case, you needn't bother yourself about this. If there might be side-effects, you now have one more thing to keep in mind.

>
>I'm convinced that it's difficult to debug programs that combine
>concurrency with mutation of shared variables. I'm not convinced, yet,
>that you can't have all of
> * concurrency
> * composition of functions without mutation
> * mutation of local (not shared) variables
>all in the same language, without trouble.
>
I'm not sure either. We'll just have to wait for someone to build it (or at least design it in detail). But you'll agree that there is no dialect of Logo that satisfies those criteria, right?

Best,

-ken kahn (www.toontalk.com)

From Brian Harvey:

"Ken Kahn" <KenKahn@ToonTalk.com> writes:
> But you'll agree that there is no dialect of
>Logo that satisfies those criteria, right?

Yes, I agree with that. (Although we really should look back at TLC Logo and RM Logo to see how they handled concurrency issues.)

What's making me so curmudeonly about TT is that with new software these days I always seem to have to give up three things to get one new thing, and, while I've learned to expect this from the likes of Microsoft, I don't want to have to put up with it from my friends! :-)

From Ken Kahn:

Brian Harvey wrote in message <740836$i2l$1@agate.berkeley.edu>...
>
>What's making me so curmudeonly about TT is that with new software
>these days I always seem to have to give up three things to get one
>new thing, and, while I've learned to expect this from the likes of
>Microsoft, I don't want to have to put up with it from my friends! :-)

I see the arithmetic a bit differently:

Logo - synchronous procedure calls - global variables - sequential execution - functional composition + concurrent execution + asynchronous procedure calls + animated programming environment + demonstrative programming + objects + many-to-many communication channels = (approximately) ToonTalk

Most of our discussion has been me been arguing why the things I've added are good and why I felt the need to remove the things I did. And you have been arguing I shouldn't have removed those things.

Best,

-ken kahn (www.toontalk.com)

From Wen "Wayne" Su:

Ken Kahn wrote in message
>I see the arithmetic a bit differently:
>
>Logo - synchronous procedure calls - global variables - sequential
>execution - functional composition + concurrent execution + asynchronous
>procedure calls + animated programming environment + demonstrative
>programming + objects + many-to-many communication channels =
>(approximately) ToonTalk


Although I may not know all these concepts well, I enjoy reading discussions among members in this news group. Although I have no clear ideas about what combinations of language features are good for elementary/middle schoolers, there is definitely something new or interesting to me in TT that makes me think.

Today, I find out that it seems there is no explicit variable identifier in TT as we have in typical, text based computer languages, in which we use a character string to identify a variable at programming or coding time. What seems to be a variable in TT is not explicitly given a name; it is just the "thing" you see on the screen, which you can put a thing into it.

If this is true, does this mean you can teach kids who do not know how to spell words yet to understand the concept of variable? I guess not. I think for kids who are too young to learn to spell, some features in TT should be temporarily disabled but some features are still age-appropriate.

About the concurrency issue, it is important in SOME context, and those kids who may become computer engineers definitely need to learn these techniques/concepts sooner or later (But I do not know how soon.) All hardware description languages used to design microprocessors are concurrent in nature. A major architecture difference between an Intel 486 microprocessor and a Pentium microprocessor is the latter executes instructions more concurrently. There are more concurrency issues that need to be addressed for the next generation CPU (More concurrency logic is going to be in the software compiler rather than the chips, though.) The question is whether or not most of us still keep programming in sequential languages, and let a selected few build the concurrent system for us. But there is a need to let at least some children learn these concepts.

>Most of our discussion has been me been arguing why the things I've added
>are good and why I felt the need to remove the things I did. And you have
>been arguing I shouldn't have removed those things.
>
>Best,
>
>-ken kahn (www.toontalk.com)
>
>

From Brian Harvey:

"Wen \"Wayne\" Su" <Wen.Su@gte.net> writes:
>The question is whether or not most of us still keep programming in
>sequential languages, and let a selected few build the concurrent system
>for us. But there is a need to let at least some children learn these
>concepts.

I don't think the design of Logo, or TT, should or does revolve around the future needs of the computer industry!  My own CS-in-Logo books are an anomaly; the features we put in languages for kids are chosen to support their general intellectual development, we hope, and more specifically to turn them into mathematicians (by which I mean formal thinkers).

The ones who will end up programming will learn what they need to learn somewhere along the line.

From Wen Su:

Brian Harvey wrote in message <744o1t$ofl$1@agate.berkeley.edu>...
>"Wen \"Wayne\" Su" <Wen.Su@gte.net> writes:
>>The question is whether or not most of us still keep programming in
>>sequential languages,
>
>I don't think the design of Logo, or TT, should or does revolve around
>the future needs of the computer industry!  My own CS-in-Logo books are
>an anomaly; the features we put in languages for kids are chosen to
>support their general intellectual development, we hope, and more
>specifically to turn them into mathematicians (by which I mean formal
>thinkers).

Well said.

I heard in most college adimissions process, a computer science course is considered as a "solid" course, but a programming course is not considered as solid as a computer science course. Is this true? There must be some reasons.

When I first learned to program (in FORTRAN IV), I thought programming was not very fun. Later, when I was learning data structures (from the book "The Art of Computer Programming" by Knuth, This was probably the only data structure book available at that time, I think.), I started to understand that there is really something interesting in this field --even though a pure education computer language called MIX is used in that book to describe algorithms in details.

Maybe students today do not learn these things from such an old book, especially if they learn that its author once wrote an article: "Goto statements considered not harmful" or something like that. (Just joking here.)

Having left schools for such a long time makes me forget what should be learned in school. At least I would not try to introduce C/C++ or BASIC to my kid who is still in the elementary school; so I still have some common sense, I think.

Thanks for reminding me what kind of learning is important in education.

--Wen Su

From Ken Kahn:

Wen "Wayne" Su wrote in message <742fo9$2vi$1@news-2.news.gte.net>...
>
>Today, I find out that it seems there is no explicit variable identifier in
>TT as we have in typical, text based computer languages, in which we use
>a character string to identify a variable at programming or coding time.
>What seems to be a variable in TT is not explicitly given a name;
>it is just the "thing" you see on the screen, which you can put a thing into
>it.
>If this is true, does this mean you can teach kids who do not know how
>to spell words yet to understand the concept of variable? I guess not.
>I think for kids who are too young to learn to spell, some features in TT
>should be temporarily disabled but some features are still age-appropriate.
>

The few times that I've watched 4 or 5 year olds use ToonTalk, I didn't see that they had any problem with the concept of variables in ToonTalk. They understand the concept that a box can have several holes or compartments. They know that if hole #1 is empty and they put something in it (let's call it A) and put something else in hole #2 (let's call it B) then if they come back to that box and take something out of hole #2 they'll get B. They understand they can then fill the hole with a new thing (C) and it'll be there if they come back. Holes in boxes really are equivalent to variables. Just because they might not understand the abstraction of variables, they
can program just fine by putting things into and taking them out of holes in a box. So why disable this for young children?

>The question is whether or not most of us still keep programming in
>sequential languages, and let a selected few build the concurrent system
>for us. But there is a need to let at least some children learn these
>concepts.
>

I agree with Brian Harvey that the primary motivation here isn't job training. ToonTalk is concurrent because I think concurrency is a better way to think about programming. Consider the ToonTalk Ping Pong game example. In ToonTalk, the ball is programmed to bounce, make sounds, and communicate with the score keeper. The paddle is programmed to follow vertical movements of the mouse. The score keeper waits for messages indicating a change and updates itself accordingly. I think, and I think nearly everyone who is a
non-programmer thinks, that it is completely natural and expected that these 3 processes are happening concurrently. (Maybe even that the 3 behaviors of the ball are 3 processes.) Contrast this with how in a sequential program one thinks about this. One has a top-level loop which reads mouse movements, then updates the paddle position, then it computes a new position for the ball, checks if it is colliding and if so computes a new velocity, it then checks if the ball has missed the paddle and if so updates the score. And
then it redisplays the paddle, ball, and score before repeating the top level loop. I believe this is natural only to programmers who have become used to dealing with a single thread of execution.

In Mitch Resnick's masters thesis, he relates a story of a girl he was trying to teach MultiLogo. The girl had mastered sequential Logo the year before. She kept ignoring MultiLogo's concurrency primitives and kept programming in a sequential manner. Mitch then asked her how she and her brother would prepare dinner for the family. She said she would stir the pot once, tell her brother to put down a fork, then she would stir it again, and tell him to put down a spoon. Then she realized how absurd this was and began to understand what Mitch was saying about concurrent programming. [Disclaimer: I read his masters thesis several years ago - and may not be remembering this story accurately.]

Best,

-ken

Brian Harvey:

"Ken Kahn" <KenKahn@ToonTalk.com> writes:
> Contrast this with how in a sequential program
>one thinks about this. One has a top-level loop which reads mouse movements,
>then updates the paddle position, then it computes a new position for the
>ball, checks if it is colliding and if so computes a new velocity, it then
>checks if the ball has missed the paddle and if so updates the score. And
>then it redisplays the paddle, ball, and score before repeating the top
>level loop.

I don't think this is quite fair.  You are assuming that the sequential language has lower-level graphics primitives than the concurrent one, I think.  Remember Atari Logo?  It was sort of "semi-concurrent"; you programmed it sequentially, but could set up daemons to detect collisions and joystick movement asynchronously.   And turtles could have speeds. The part about first checking the ball position and then updating the score is true, though.  So, once again, my question is not "is there any virtue to concurrency?" (clearly yes) but rather "do we have to give up procedure calling and make everything fit into the Procrustean (sp?) bed of threads?"  Maybe there is a more incremental change possible.

From Ken Kahn:

Brian Harvey wrote in message <74ceon$4fn$1@agate.berkeley.edu>...

>Remember Atari Logo?  It was sort of "semi-concurrent"; you
>programmed it sequentially, but could set up daemons to detect collisions
>and joystick movement asynchronously.  And turtles could have speeds.
>The part about first checking the ball position and then updating the
>score is true, though.  So, once again, my question is not "is there any
>virtue to concurrency?" (clearly yes) but rather "do we have to give up
>procedure calling and make everything fit into the Procrustean (sp?) bed
>of threads?"  Maybe there is a more incremental change possible.

I do remember Atari Logo and was excited about it at the time.

I think the core of our friendly disagreement is that I want a kind of uniformity. The approach of Atari Logo was to provide support for some common special cases. But it didn't give you support for others. Nor did it provide a smooth transition from built-in concurrency to the user defined. A demon can wait for a collision and then run some procedure. But can a demon wait for some user defined condition? I don't think so. I favor a uniformly concurrent model of computation because it subsumes sequential procedure
calls. I don't give up on them, I just don't provide any support. But a ToonTalk user can express a sequential synchronous procedure call - by training a robot to load up a truck with robots and box with a bird and then arranging for the team of robots to wait until the one of the robots that was put in the truck gives the bird the "return value". Admittedly, it is more awkward than in other kinds of languages.

As a language designer, one is often faced with the question of whether to give primitive, low-level support for common special cases of what a more general mechanism can do. Doing so will make some programs easier to express, but is likely to add complexity (for the learner, user, and implementer). I believe a novice will find it easier to deal with computations that are concurrent than computations which have both concurrent and sequential parts.

Best,

-ken kahn (www.toontalk.com)

From luvisi@andru.sonoma.edu:

disclaimer: I haven't seen ToonTalk.  I don't use Windows.

conjecture: ToonTalk is not capable of serving as a development
environment for all applications one will ever wish to create.  that
is, anyone who keeps programming long enough, and keeps making more
and more complex and/or functional programs will, eventually,
"outgrow" ToonTalk.

this is based entirely on my observation of the conversation in this
newsgroup so far, and a few visits to the ToonTalk web site.

if this conjecture is correct, I would be curious as to when/how you
(Ken Kahn) would expect a child who kept "doing more" to "outgrow"
ToonTalk.  I would also be curious as to where you would recomend
they go when this happened.  perhaps another way of putting this is:
you clearly view ToonTalk as a "first step" in a progression... what
else do you see in that progression?

if this conjecture is incorrect, I would very much like to know your
reasoning as to why/how.

part of the reason I'm asking this is the same reason I started
following this newsgroup a couple weeks ago.  I'm trying to understand
this amorpheous concept of "easy" as applied to computer use and
programming.  also, can you name any other environments which share
what you believe to be ToonTalk's most essential features?

* warning, the part below is a long description of my personal search for
* enlightenment.  it's longer than I intended, and is mostly
* questions...
* it's also directed at anyone who'll listen, rather than just Ken Kahn

I've dealt with many clients who are trying to learn perl so they can
write CGIs, and I came to the conclusion early on that perl, while
terribly convenient for many applications, is a lousy first language
(even for adults).  well, these people would, naturally, be happy
writing in any other language... preferably the "easiest" one for
them...  so I started trying to come up with something I could recomend
as an alternative to perl...

when I asked many months ago on comp.lang.perl.misc "is perl a good
first language?", I got responses which mostly echoed my own thoughts.
namely: it is not a good first language, and the main reason was
because it is incredibly inconsistent.  someone learns a "rule", and
then they keep getting nailed by exceptions to that rule, until they
have more or less memorized all of the exceptions.  much like english
spelling.

...so I figured out that consistency is an important part of something
being "easy", but I know there's other things.

I like awk myself, and use it for many things, since it has a high
degree of consistency, but beginners seem to have trouble wrapping
their minds around the whole "implicit loop" thing (for perl users,
awk always has the behavior perl has with the -n option).  awk was
designed to allow an advanced user to do a medium level custom
filtering job on a file with one line of code.  other things came as
conveniences, and the authors admit it wasn't designed to be a "first
language" (though they don't offer any thoughts on what would be better).
there's a lesson here, but I don't know what it is...  don't start
with a specialized language?

BASIC (is that a bad word here?), as I learned it on the apple II, is
a very consistent language.  it is also "easy" to grasp at first, but
once a programmer starts trying to do anything requiring more than a
couple thought processes to execute, he finds himself in spaghetti
code.  then he finds gosub/return, which takes care of him up to maybe
one or two hundred lines or so, but then he starts having problems
with all variables being global(!).  and by then, he can have habits
which are hard to break when he finds a language with dynamic scoping
(oh cool!) or lexical scoping (wow!), or a while loop.  I *hated*
having to use whiles instead of gotos when I first was learning C.  I
had learned to use gotos in DCL rather than BASIC, but I can empathize
with the BASIC programmer unlearning the same bad habbit.  I think the
lesson here is that while gotos are easy, they should be left out of
(or at least not encouraged) in a first language.

C++, like perl, has all sorts of "magic" in it... the same expression
can mean all sorts of things depending on the context...

I think C is a better first language than C++ because it has so much
less "magic", but string handling is such a pain to do right in C,
and so dangerous to do wrong... it seems wrong to me to teach budding
programmers dangerous practices like:

main()
{
char name[100];

printf("What is your name? ");
scanf("%s", name);
printf("Hello %s!\n", name);
}

but the alternative is to make them do it the correct way.  and to
write a safe version of the above, I can't think of anything simpler than:

main()
{
char name[100];
int i;

printf("What is your name? ");
fgets(name, 100, stdin);
name[99] = '\0';

for(i=0; i < 100; ++i)
  if(name[i] == ' ' || name[i] == '\t' || name[i] == '\n')
  {
   name[i] = '\0';
   break;
  }

printf("Hello %s!\n", name);

but this isn't a suitable "second" program, the way the above is... it
doesn't have just input and output.  it also has conditionals, loops,
character constants, strings-as-null-terminated-arrays-of-chars, etc.

while in my search for understanding with respect to what makes a good
first language, and what makes something "easy", I saw a manual for
AppleLogoII at the local friends of the library book sale.  I happen
to own several Apple IIs (love the things, and they serve as a
constant reminder to me of why I use Linux.  no one company or person
can kill Linux the way Apple killed the Apple II.  but I digress.)
thinking "hay, logo's for kids.  it must be easy.  maybe it would make
a good case study.", I bought it, picked myself up a copy of
AppleLogoII, and started learning it.  frankly, it just reminded me of
elisp (the only lisp dialect I am very familiar with, though I know a
*teeny* bit of scheme) with some different names, and '(...) replaced
with [...] and '... replaced with "... .

all the same concepts... recursion, variables, itteration via tail
recursion, minus things like non-argument local variables.

now, I've played with ucblogo, and I've seen many of the improvements
and enhancements in it, but I still don't get what I came trying to
understand...

-> what is it about logo (or any other language) that is supposed to make
-> it "easy", and good as a first language?

-> how is it that logo (or any other language) allows people to "easily"
-> express to the computer their thought process?

I think I (more of less) understand how ToonTalk acomplishes these,
based on Ken Kahn's multitude of kind explanations, but I'm curious
about how he or anyone else would suggest someone move from the Toon
Talk world into something more useful, and where an adult should
begin this same journey.

perhaps I'm just a little bit lost in trying to understand the best
progression for a learning programmer since my first language was DCL.
you could say I had a broken programmer's childhood and am now trying
to understand what a healthy one is like :-)

my apologies if I have gone too far off topic for this group...  I'm
certainly interested in hearing about any other more or equally
appropriate places to bring up these questions.

I guess at the heart of it, I'm trying to figure out, in general,
what's the best answer to "I want to learn how to program.  where
should I start?", and in particular, what's the best answer to "I want
to write CGIs for my web site.  where should I start learning?".  I'm
also, however, trying to get a handle on what it means for a language
or programming environment to be "intuitive" or "easy".

andru

From Ken Kahn:

luvisi@andru.sonoma.edu wrote in message ...

>conjecture: ToonTalk is not capable of serving as a development
>environment for all applications one will ever wish to create.  that
>is, anyone who keeps programming long enough, and keeps making more
>and more complex and/or functional programs will, eventually,
>"outgrow" ToonTalk.
>


The current version of ToonTalk has many limitations and shortcomings. Its
ability to manipulate text strings is so-so. Its ability to do file I/O is
minimal. There are no floating point numbers. It requires a large and slow
programming environment to run programs. It currently is able to deal with
user media only as BMP or WAV files. You can re-train robots but you can't
edit their behavior. So, I would not try to build a web browser in ToonTalk.
The only reasonable way ToonTalk could be used for CGI programming would be
to build the program in ToonTalk and then use the Java translation on the
server.

>if this conjecture is correct, I would be curious as to when/how you
>(Ken Kahn) would expect a child who kept "doing more" to "outgrow"
>ToonTalk.  I would also be curious as to where you would recomend
>they go when this happened.  perhaps another way of putting this is:
>you clearly view ToonTalk as a "first step" in a progression... what
>else do you see in that progression?
>
Maybe in a few years there will be a ToonTalk Pro or ToonTalk version 5.0
(currently at 1.04) which won't be outgrown. In other words, I don't see any
reason to outgrow the core ideas of ToonTalk computation model and
programming environment. It is only the current implementation that might be
outgrown.

If a child mastered ToonTalk and wanted to do things it currently can't do,
I guess that Java is the best next step. I see ToonTalk's ability to produce
the Java equivalent of whatever a child has made as a bridge or stepping
stone to make the transition to Java a bit easier.

>
>part of the reason I'm asking this is the same reason I started
>following this newsgroup a couple weeks ago.  I'm trying to understand
>this amorpheous concept of "easy" as applied to computer use and
>programming.  also, can you name any other environments which share
>what you believe to be ToonTalk's most essential features?
>

This is a really good question and I hope others try to answer it as well.
One thing I've observed with kids and ToonTalk is that they very quickly
learn the language primitives. Where they get stuck is they lack design
skills - they know no programming techniques. This is how I feel when I play
with Lego Technic gears. I understand how gears work but I can't build a
very good Lego car.

There are many languages that share ToonTalk's model of computation -
Concurrent Prolog, Parlog, Guarded Horn Clauses, Strand, KL1, OC, Herbrand,
Janus, Linear Janus, and Oz. I think these languages aren't better known
because programmers have found them hard to learn. I suspect this is mostly
because programmers have already learned a very different way of thinking
about programming.

There are no other environments that I know of that enable you to do general
purpose programming within a game-like world. Robot Odyssey and Rocky's
Boots (popular games from the early 1980s) let you express circuits and
boolean computations in a game-like world. Stagecast Creator (formerly known
as KidSim and Cocoa) makes it easy for kids to express some kinds of
programs as picture re-write rules.

>
>...so I figured out that consistency is an important part of something
>being "easy", but I know there's other things.
>

I think a good learnable language should have a small but powerful kernel.
E.g. ToonTalk or Scheme. You then get consistency because most everything
else is built upon the kernel.
>
>BASIC (is that a bad word here?), as I learned it on the apple II, is
>a very consistent language.  it is also "easy" to grasp at first, but
>once a programmer starts trying to do anything requiring more than a
>couple thought processes to execute, he finds himself in spaghetti
>code.

Back in the 1970s and early 1980s BASIC was a bad word in the Logo
community. But I don't know how the newer, better implementations of Basic
are viewed today. Visual Basic seems pretty reasonable these days - it has
recursive procedures, reasonable variable names, etc.

>
>C++, like perl, has all sorts of "magic" in it... the same expression
>can mean all sorts of things depending on the context...
>
>I think C is a better first language than C++ because it has so much
>less "magic",

Interesting. By "magic" do you mean that the underlying mechanism is complex
and farther from the hardware? Would you argue against Java in the same way?

Best,

-ken kahn (www.toontalk.com)

From luvisi@andru.sonoma.edu:

"Ken Kahn" <KenKahn@ToonTalk.com> writes:
> Maybe in a few years there will be a ToonTalk Pro or ToonTalk version 5.0
> (currently at 1.04) which won't be outgrown. In other words, I don't see any
> reason to outgrow the core ideas of ToonTalk computation model and
> programming environment. It is only the current implementation that might be
> outgrown.

ever plan to make it self hosting?  :-)


[snip]
> One thing I've observed with kids and ToonTalk is that they very quickly
> learn the language primitives. Where they get stuck is they lack design
> skills - they know no programming techniques. This is how I feel when I play
> with Lego Technic gears. I understand how gears work but I can't build a
> very good Lego car.

isn't that the way it is with anyone first learning to program?  I
remember an assignment from my first programming course back in my
college days.  we were to write a program to ask the user to type in
words and the program would tell the user if each word was a
palindrome or not.  it was the first assignment most of the students
had a problem with.  to follow the lego example, it was the first time
they had to build something rather than prove they knew which part of
one lego fit into which part of the next.  the course was in C, and
everyone knew how to use loops, char arrays, conditionals, and so on,
but they didn't have any idea how to start putting them together.
this is the only intro to programming course I've ever observed, not
being a teacher myself, so my sample is a bit small, but I would not
be surprised to hear that what you describe is a common pattern.

> There are many languages that share ToonTalk's model of computation -
> Concurrent Prolog, Parlog, Guarded Horn Clauses, Strand, KL1, OC, Herbrand,
> Janus, Linear Janus, and Oz. I think these languages aren't better known
> because programmers have found them hard to learn. I suspect this is mostly
> because programmers have already learned a very different way of thinking
> about programming.

could you provide any urls or book recomendations?  as a professional
problem solver, and a human being in general, I am always trying to
find new ways to look at problems.

> There are no other environments that I know of that enable you to do general
> purpose programming within a game-like world. Robot Odyssey and Rocky's
> Boots (popular games from the early 1980s) let you express circuits and
> boolean computations in a game-like world. Stagecast Creator (formerly known
> as KidSim and Cocoa) makes it easy for kids to express some kinds of
> programs as picture re-write rules.

one hypothesis that bounced around in my head was that logo wasn't
actually any easier than lisp.  maybe it's just that since it has such
a short initial "start typing" to "see something cool" curve, kids are
more willing to put the effort into learning logo since they receive
encouragement of a sort early on.

> I think a good learnable language should have a small but powerful kernel.
> E.g. ToonTalk or Scheme. You then get consistency because most everything
> else is built upon the kernel.

I've heard this about scheme many times before, which is why I've
recently begun reading the standard.  one of the things that I've
found annoying about elisp is remembering which builtins are special
forms/macros, and which ones are normal functions.  that is, if I want
to supply a function with a symbol, do I quote the symbol, or not?
for instance, (setq hi "there") is the same as (set 'hi "there").

> >C++, like perl, has all sorts of "magic" in it... the same expression
> >can mean all sorts of things depending on the context...
> >
> >I think C is a better first language than C++ because it has so much
> >less "magic",

> Interesting. By "magic" do you mean that the underlying mechanism is complex
> and farther from the hardware? Would you argue against Java in the same way?

by magic, I mean weird, special case syntactic sugar.  I'm using it in
the sense that one would say "in perl, <> as the only condition in a
while loop is magic, sinse it does all these special things."
...things which just don't make sense until you've had enough real
world experience to see why they are valuable...

considder the difference between:
cout << 2 << 3;      ==    ( cout.operator<<( 2 ) ).operator<<( 2 );
=> 23
and:
cout << (2 << 3);    ==       cout.operator<<( 2 << 3 );
=> 16

am I the only one who finds this a little bit screwy?

properly used, operator overloading, function overloading, and various
other features of C++ can be great.  while I would recomend C++ for
certain types of large projects, when used by knowledgable and highly
competent programmers, I wouldn't currently recomend it as a first
language.  but then again, I'm still forming my opinions on the
subject, and reserve the right to change my mind at any time.

as far as java goes, the last time I touched it was when it was brand
new, and while I was impressed with many of the ideas in the language,
the implimentation kept crashing on everything I wrote which was
longer than 50 lines or so, so I never got really intimate with it...

giving it another try has been somewhere near the middle of my todo
list for a while now.

thanks for the thoughtful responses,
andru

From Ken Kahn:

luvisi@andru.sonoma.edu wrote in message ...
>> There are many languages that share ToonTalk's model of computation -
>> Concurrent Prolog, Parlog, Guarded Horn Clauses, Strand, KL1, OC,
Herbrand,
>> Janus, Linear Janus, and Oz.

>could you provide any urls or book recomendations?  as a professional
>problem solver, and a human being in general, I am always trying to
>find new ways to look at problems.
>

Very good but theoretical:
Concurrent Constraint Programming (Acm Doctoral Dissertation Awards)
Vijay A. Saraswat / Hardcover / Published 1993
Our Price: $55.00 (Special Order)
Read more about this title...

Haven't read it but I should. Looks good:
Objects for Concurrent Constraint Programming (Kluwer International Series
in Engineering and Computer Science, 426)
Martin Henz / Hardcover / Published 1997

A bit old but a very good collection of papers:
Concurrent Prolog : Collected Papers (Logic Programming Series)
Ehud Shapiro(Editor) / Hardcover / Published 1988

>
>considder the difference between:
>cout << 2 << 3;      ==    ( cout.operator<<( 2 ) ).operator<<( 2 );
>=> 23
>and:
>cout << (2 << 3);    ==       cout.operator<<( 2 << 3 );
>=> 16
>
>am I the only one who finds this a little bit screwy?
>


Seeing this makes me glad that syntax errors and confusions are a non-issue
for ToonTalk.

Best,

-ken kahn (www.toontalk.com)

From Brian Harvey:

luvisi@andru.sonoma.edu writes:
>conjecture: ToonTalk is not capable of serving as a development
>environment for all applications one will ever wish to create.  that
>is, anyone who keeps programming long enough, and keeps making more
>and more complex and/or functional programs will, eventually,
>"outgrow" ToonTalk.

Ken's answer to this was about the theoretical capabilities of the
program, but what drives me crazy in TT is the user interface -- the
fact that when you want to add two numbers you have to sit there for
several seconds watching this funny-the-first-time animation of the
rat with the hammer.  The fact that I can't get the sorcerer's
apprentice vacuum cleaner to stop deleting things!  (I mean, I can
eventually, but not until it's eaten three things I wanted.)  Stuff
like that.  I bet kids outgrow that before they outgrow the set of
problems TT can program.

>...so I figured out that consistency is an important part of something
>being "easy", but I know there's other things.

There's actually a good deal of disagreement among Logo people about
the consistency question.  The early MIT Logos (whence Terrapin Logo
and friends) have a BASIC-style IF/THEN special form.  At LCSI we
decided to eliminate all special forms except TO; our IF is an ordinary
procedure whose arguments must be quoted to avoid premature evaluation.
MIT: IF 2=3 THEN PRINT "HELLO
LCSI: IF 2=3 [PRINT "HELLO]
I like the LCSI way better because it's more uniform and therefore
easier to model, but I'm not sure it's "easier" for beginners.  It
would be if the beginners were taught the model of applicative order
evaluation, but they're not; they're taught "just remember to put
brackets around the thing you want IF to run conditionally."  So it
can *seem* to be *less* uniform!

Aside from obvious dreadful mistakes, like the fact that STATIC means
four, count them, four completely unrelated things in C++, I've come
to believe that there's no such thing as easy or hard language features;
it all depends on what you're used to.  Well, maybe except for call/cc
in Scheme... that's hard... but when it comes to choosing a paradigm,
functional is easiest if you're accustomed to doing math, but not
otherwise, and I suspect some similar thing is true about concurrent
programming.

>  frankly, [Logo] just reminded me of
>elisp (the only lisp dialect I am very familiar with, though I know a
>*teeny* bit of scheme) with some different names, and '(...) replaced
>with [...] and '... replaced with "... .
>all the same concepts... recursion, variables, itteration via tail
>recursion, minus things like non-argument local variables.

I think Apple Logo II has LOCAL, doesn't it?

But otherwise, indeed, Logo is basically Lisp.  They left out the
parentheses because they scare people; they added infix arithmetic.
At the time Logo was designed, dynamic scope was standard for Lisp
interpreters, so we didn't even have to think about that, although
even today I stand by that choice for Logo.

>-> what is it about logo (or any other language) that is supposed to make
>-> it "easy", and good as a first language?

At the time, we argued that lists are more natural than arrays, because
you don't have to count how big to make them, and you don't have to
introduce index variables that really aren't relevant to your problem.
Recursion is (we said) more natural than things like FOR loops,
especially if you think in terms of little people (so that you focus
on invocations, rather than on procedures). 

Also, a lot of design effort went into the error messages.  It was
particularly easy to make fun of BASIC back then, which mostly said
SYNTAX ERROR no matter what you did wrong.  We had arguments about
whether "I don't know how to XXX" is better or worse than "you don't
say how to XXX" (that is, is it good or bad to personify the computer),
and then there was Paul Goldenberg's brilliant idea to put an extra
space in, as in "You don't say how  to XXX" to help remind the user
that TO is what you use to fix it!

From Ken Kahn:

Brian Harvey wrote in message <74cgpg$4sr$1@agate.berkeley.edu>...

>Ken's answer to this was about the theoretical capabilities of the
>program, but what drives me crazy in TT is the user interface -- the
>fact that when you want to add two numbers you have to sit there for
>several seconds watching this funny-the-first-time animation of the
>rat with the hammer.  The fact that I can't get the sorcerer's
>apprentice vacuum cleaner to stop deleting things!  (I mean, I can
>eventually, but not until it's eaten three things I wanted.)  Stuff
>like that.  I bet kids outgrow that before they outgrow the set of
>problems TT can program.
>
Kids adapt rather than outgrow. And there are good reasons why the interface
is the way it is. If you had to wait every time for the mouse with a hammer,
then I would agree with you. But ToonTalk isn't just a concurrent
programming system, it is a concurrent programming environment as well. You
can drop a number on a number and start working on the next thing, confident
that the mouse will add them together while you are doing the next thing.
There was a time when the vacuum cleaner vacuumed up one thing when you
turned him on. But real vacuums stay on until you turn them off. And the
bike pump has an even stronger need to be on until you turn him off. You
want to slowly change the dimensions of something until it is the way you
want and then stop pumping.

The only kid who I've heard complain about the interface was 14 years old.
And you were there last month, when a 9 year old at the BayCHI Kids meeting
walked up to ToonTalk "cold" and did very well with it without help.

Best,

-ken kahn (www.toontalk.com)

principal | procura | compra | manual | notícias | informação | perguntas | apoio | downloads | imprensa | contacto