The following discussion inspired me to write a paper on the topic over 2 years later.
This is a discussion that was held on comp.lang.logo (and the corresponding email discussion list) from November 16 to December 2, 1998. The discussion entitled "Is Logo old technology?" was started by the following message:
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