Hi guys...
Preparing the content in Spanish for Small-Land I found one question I'm not able to respond.
"Why use Squeak instead of Logo?"
I know almost nothing about Logo, but from my (limited) point of view I think the key difference is the Object Orientation.
The Object paradigm is, imho, a better way to describe the reality than the "Structured way" used by Logo. Also I can find some roots in some "knowledge representation" theories (the pair object-subject).
The "dark" point with my thought is I'm not able to see if this argument is valid for teachers/educators.
I'd like to hear your opinions.
Diego Gomez Deck http://www.small-land.org
PS: Anyone knows the Papert's feeling about Squeak? I guess it's good (based on the Squeaker movie :))
Hi Diego and folks --
There is no "versus" here. Logo is great, and it was the inspiration for much of what we've done over the years. In fact, I've been encouraging the Logo folks at MIT -- Seymour Papert and Mitchel Resnick have been long time colleagues and advisors -- to actually put a Logo on top of Squeak -- pretty much everything is already there except the syntax and UI.
Before I mention a few differences in point of view, let me say that the main aim here is to teach children real math and real science, and this can be done just fine with Logo. However, with both Logo and Squeak it really helps for the teachers to already understand real math and real science beforehand, or to really try to learn the real subjects and processes along with the children. (In the United States, most elementary school teachers are not fluent in real math and real science, and the official curricula are not about the real subjects, but about "rules for calculation" instead of real math, and "science facts to memorize" instead real science.)
There have been many variants of Logo, all with a fairly similar syntax. There have been several versions that are more or less object oriented, with a number of different syntaxes to deal with addressing messages or commands to different objects. The more recent versions of Logo have sprites with costumes, and these are basically objects.
In the late sixties, influenced by Logo and by some previous object-oriented work I'd done, I started thinking about object-oriented languages for children. One simplifying idea was to have everything the child encounted be an object, so there was only one coherent world view to understand and use and just one way to get objects to do things.
In Squeak, this simplification goes even further, so that every object is also "a turtle with a costume" -- (make a script in Squeak, get its halo, and look at its viewer. You will seen "forward" and "turn". Look at the "pen" category, and you will see that the script itself has a pen. Thus you can easily make a script for the script that will make it move in a circle!) The basic ideas here are simplicity, uniformity, a glimpse into the metanature of computing, etc.
Another noticable difference in Squeak is the tiles UI. This has turned out to be great for beginners of all ages. It really encourages rapid experimentation early one without worries about syntax, spelling, etc.
A current "drawback" in the Squeak etoys is that they were an experiment aimed at a particular age group -- 9 to 12 year olds -- for particular purposes -- about 50 etoys in math and science. The good news is that, in this range, they really work extremely well, and are learned by virtually all children and adults who try them. That was the experiment. The downside is that there is not a lot of extension in the current system, and it gets awkward for older children and experts.
For the last several years, we've been working on a version of this that starts out as easy to use as the Squeak etoys but is much more graceful in how it expands as a learner gets more fluent. We will put this new version out as an experiment this Fall for those who are interested. This version can carry multiple syntaxes, and it's likely that one of them will be a variant of Logo -- that would be fine with us -- this would make a large world of Logo documentation available to all.
Just a pause for a thought here ... Neither the current Squeak syntax nor the Logo syntaxes are ideal for children and other end users. We really should be thinking about what improvements in UI should be made to help them. Andreas Raab has pointed out that the syntax of a programming language is actually part of its user interface -- and I think this is a really important observation. If we look at the difficulties of having children understand (say) parameter passing in Logo, we should be thinking about how it should look. (It should probably look more like explict assignments to the internal variables of the procedure than the blind magic that now exists. I left parameters out in the first version of etoys for this very reason. It is much easier for the children to make exlicit assignments to the local instance variables in the parent object before calling the procedure. But this doesn't work for recursion, so what should probably be in there is a tile that bundles up the assignments and the call. Etc.)
"Functions" and things like functions are a powerful idea. So we should be thinking about how to make this stuff better, not just how to make use of it or to ignore what the children have difficulty with. It's not that difficult to make languages and UIs for different ages and sophistications, but it is quite difficult to make the graceful blend and path from the simpler to the more sophisticated.
In the sixties, there were lots of computers and lots of different computer languages. Most practitioners back then quickly got "multilingual" and learned to program in many languages. Nowadays, different syntaxs seem to be a much greater barrier, and it seems worthwhile to cater a little more to this barrier in order to try to teach the underlying ideas.
Cheers,
Alan
At 7:01 AM -0500 8/8/03, diegogomezdeck@consultar.com wrote:
Hi guys...
Preparing the content in Spanish for Small-Land I found one question I'm not able to respond.
"Why use Squeak instead of Logo?"
I know almost nothing about Logo, but from my (limited) point of view I think the key difference is the Object Orientation.
The Object paradigm is, imho, a better way to describe the reality than the "Structured way" used by Logo. Also I can find some roots in some "knowledge representation" theories (the pair object-subject).
The "dark" point with my thought is I'm not able to see if this argument is valid for teachers/educators.
I'd like to hear your opinions.
Diego Gomez Deck http://www.small-land.org
PS: Anyone knows the Papert's feeling about Squeak? I guess it's good (based on the Squeaker movie :))
Squeakland mailing list Squeakland@squeakland.org http://squeakland.org/mailman/listinfo/squeakland
--
Hi Alan...
Your answer, as usual, gives me too many things to think about... thanks!
Your email is really clear but I'd like to know what is your feeling about the environment in Smalltalk. (I don't know if any version of Logo share with ST the environment idea).
Is the environment an important tool for teaching?
I guess the environment and a diary/periodical work on it can help to teach how to participate in bigger environments and how to be a par in complex- systems. Do you have any experience/thought on this topic?
TIA,
Diego
Hi Diego and folks --
There is no "versus" here. Logo is great, and it was the inspiration for much of what we've done over the years. In fact, I've been encouraging the Logo folks at MIT -- Seymour Papert and Mitchel Resnick have been long time colleagues and advisors -- to actually put a Logo on top of Squeak -- pretty much everything is already there except the syntax and UI.
Before I mention a few differences in point of view, let me say that the main aim here is to teach children real math and real science, and this can be done just fine with Logo. However, with both Logo and Squeak it really helps for the teachers to already understand real math and real science beforehand, or to really try to learn the real subjects and processes along with the children. (In the United States, most elementary school teachers are not fluent in real math and real science, and the official curricula are not about the real subjects, but about "rules for calculation" instead of real math, and "science facts to memorize" instead real science.)
There have been many variants of Logo, all with a fairly similar syntax. There have been several versions that are more or less object oriented, with a number of different syntaxes to deal with addressing messages or commands to different objects. The more recent versions of Logo have sprites with costumes, and these are basically objects.
In the late sixties, influenced by Logo and by some previous object-oriented work I'd done, I started thinking about object-oriented languages for children. One simplifying idea was to have everything the child encounted be an object, so there was only one coherent world view to understand and use and just one way to get objects to do things.
In Squeak, this simplification goes even further, so that every object is also "a turtle with a costume" -- (make a script in Squeak, get its halo, and look at its viewer. You will seen "forward" and "turn". Look at the "pen" category, and you will see that the script itself has a pen. Thus you can easily make a script for the script that will make it move in a circle!) The basic ideas here are simplicity, uniformity, a glimpse into the metanature of computing, etc.
Another noticable difference in Squeak is the tiles UI. This has turned out to be great for beginners of all ages. It really encourages rapid experimentation early one without worries about syntax, spelling, etc.
A current "drawback" in the Squeak etoys is that they were an experiment aimed at a particular age group -- 9 to 12 year olds -- for particular purposes -- about 50 etoys in math and science. The good news is that, in this range, they really work extremely well, and are learned by virtually all children and adults who try them. That was the experiment. The downside is that there is not a lot of extension in the current system, and it gets awkward for older children and experts.
For the last several years, we've been working on a version of this that starts out as easy to use as the Squeak etoys but is much more graceful in how it expands as a learner gets more fluent. We will put this new version out as an experiment this Fall for those who are interested. This version can carry multiple syntaxes, and it's likely that one of them will be a variant of Logo -- that would be fine with us -- this would make a large world of Logo documentation available to all.
Just a pause for a thought here ... Neither the current Squeak syntax nor the Logo syntaxes are ideal for children and other end users. We really should be thinking about what improvements in UI should be made to help them. Andreas Raab has pointed out that the syntax of a programming language is actually part of its user interface -- and I think this is a really important observation. If we look at the difficulties of having children understand (say) parameter passing in Logo, we should be thinking about how it should look. (It should probably look more like explict assignments to the internal variables of the procedure than the blind magic that now exists. I left parameters out in the first version of etoys for this very reason. It is much easier for the children to make exlicit assignments to the local instance variables in the parent object before calling the procedure. But this doesn't work for recursion, so what should probably be in there is a tile that bundles up the assignments and the call. Etc.)
"Functions" and things like functions are a powerful idea. So we should be thinking about how to make this stuff better, not just how to make use of it or to ignore what the children have difficulty with. It's not that difficult to make languages and UIs for different ages and sophistications, but it is quite difficult to make the graceful blend and path from the simpler to the more sophisticated.
In the sixties, there were lots of computers and lots of different computer languages. Most practitioners back then quickly got "multilingual" and learned to program in many languages. Nowadays, different syntaxs seem to be a much greater barrier, and it seems worthwhile to cater a little more to this barrier in order to try to teach the underlying ideas.
Cheers,
Alan
At 7:01 AM -0500 8/8/03, diegogomezdeck@consultar.com wrote:
Hi guys...
Preparing the content in Spanish for Small-Land I found one question I'm not able to respond.
"Why use Squeak instead of Logo?"
I know almost nothing about Logo, but from my (limited) point of view I think the key difference is the Object Orientation.
The Object paradigm is, imho, a better way to describe the reality than the "Structured way" used by Logo. Also I can find some roots in some "knowledge representation" theories (the pair object-subject).
The "dark" point with my thought is I'm not able to see if this argument is valid for teachers/educators.
I'd like to hear your opinions.
Diego Gomez Deck http://www.small-land.org
PS: Anyone knows the Papert's feeling about Squeak? I guess it's good (based on the Squeaker movie :))
As long as we are being ecumenical, don't forget about Andy diSessa and his (and earlier Hal Abelson's) Boxer work that has been going on for many years at Berkeley. A recent deep book about this is:
http://www.amazon.com/exec/obidos/tg/detail/-/0262041804/qid=1060452055/sr=1...
There are many great ideas and valuable insights here.
Cheers,
Alan --
Alan Kay wrote:
Just a pause for a thought here ... Neither the current Squeak syntax nor the Logo syntaxes are ideal for children and other end users. We really should be thinking about what improvements in UI should be made to help them. Andreas Raab has pointed out that the syntax of a programming language is actually part of its user interface -- and I think this is a really important observation. If we look at the difficulties of having children understand (say) parameter passing in Logo, we should be thinking about how it should look.
I'd like to urge that people consider radical alternatives to textual syntaxes. Syntaxes based upon diagrams or pictures have had limited success either because they weren't very general or, despite being visual, they were too abstract and difficult for children and other end users. But there are alternatives to text (even with tiles) and to pictures. My ToonTalk (www.toontalk.com) is an example. The equivalent of a Squeak method in ToonTalk are the actions you train a robot to take in a game-like animated world. Syntax isn't a good way to think about such things. What is the syntax of showing someone how to tie a know for example?
Programs in any language are created, composed, edited, debugged, and studied (typically by reading the source code). ToonTalk currently excels in creation, debugging, and composition and is very weak for editing. And rather than study the source of ToonTalk program you can watch it to understand what it does. The shortcoming with editing and studying programs can perhaps be overcome - e.g. Mikael Kindborg's work on comic strip programming (http://www.ida.liu.se/~mikki/comics/index.html).
Another open question is whether a good animated syntax can be found for all computation models.
I think the fundamental idea underlying ToonTalk is that programming can be made very concrete without giving up any expressive generality. For young children this concreteness is especially important. In ToonTalk parameter passing isn't difficult - it is just giving boxes full of stuff to birds or robots. Even 4 year olds are able to understand and accomplish a lot - see Leonel Morgado's thesis-in-progress - e.g. http://www2.cs.fau.de/HCC01/proposals/Morgado-paper.pdf
Best,
-ken
Hi Ken --
There are definitely a lot of good ideas in ToonTalk -- and, as you know, I've been interested in various kinds of iconic programming for many years. I think some nifty combination of iconic and symbolic elements (yet to be discovered) will indeed be part of a much better authoring system for all.
Your knot example is a good one, but so is the fact that you used English to state your case below. I think you would agree that a combination of English and pictures and actual manipulatives would be even better, just as quite a bit of math is difficult to express only in pictures, though pictures and manipulatives are a great way to start off.
Cheers,
Alan
At 1:08 PM +0100 8/9/03, Ken Kahn wrote:
Alan Kay wrote:
Just a pause for a thought here ... Neither the current Squeak syntax nor the Logo syntaxes are ideal for children and other end users. We really should be thinking about what improvements in UI should be made to help them. Andreas Raab has pointed out that the syntax of a programming language is actually part of its user interface -- and I think this is a really important observation. If we look at the difficulties of having children understand (say) parameter passing in Logo, we should be thinking about how it should look.
I'd like to urge that people consider radical alternatives to textual syntaxes. Syntaxes based upon diagrams or pictures have had limited success either because they weren't very general or, despite being visual, they were too abstract and difficult for children and other end users. But there are alternatives to text (even with tiles) and to pictures. My ToonTalk (www.toontalk.com) is an example. The equivalent of a Squeak method in ToonTalk are the actions you train a robot to take in a game-like animated world. Syntax isn't a good way to think about such things. What is the syntax of showing someone how to tie a know for example?
Programs in any language are created, composed, edited, debugged, and studied (typically by reading the source code). ToonTalk currently excels in creation, debugging, and composition and is very weak for editing. And rather than study the source of ToonTalk program you can watch it to understand what it does. The shortcoming with editing and studying programs can perhaps be overcome - e.g. Mikael Kindborg's work on comic strip programming (http://www.ida.liu.se/~mikki/comics/index.html).
Another open question is whether a good animated syntax can be found for all computation models.
I think the fundamental idea underlying ToonTalk is that programming can be made very concrete without giving up any expressive generality. For young children this concreteness is especially important. In ToonTalk parameter passing isn't difficult - it is just giving boxes full of stuff to birds or robots. Even 4 year olds are able to understand and accomplish a lot - see Leonel Morgado's thesis-in-progress - e.g. http://www2.cs.fau.de/HCC01/proposals/Morgado-paper.pdf
Best,
-ken
--
I've worked with both Logo and Squeak and my research group has been having a lot of Logo/Squeak discussions lately. I'm with the Future of Learning Group at the MIT Media Lab, and recently I've had the great opportunity to work with John Maloney on Squeak after a year and a half of plowing through it on my own. I've also had a number of conversations with Seymour about Logo and Squeak.
My quick critique of Squeak is that there are a number of great things about it, but it doesn't meet its potential. It's completely object-oriented, allows children to program many different types of media and one of the biggest selling points for me-- it's open-source. It's free for schools to use and developers and teachers can make all sorts of modifications. This has been really helpful in projects that I've done. Logo is lacking here. I've mostly used Microworlds Logo or Imagine. What I find frustrating is that the only object is a turtle. This is great for the geometry microwold for which Logo was designed. It's a very elegant language and environment. But it isn't very extensible, either to different forms of media, or to communicating with hardware-- both of which are simple tasks in Squeak.
There are a few big problems with Etoys, however. The biggest one, in my opinion, is that it completely limits the object-orientedness of Squeak. In Etoys, one cannot create a new class of objects-- just new instances of objects. I can create and program an object, then copy it so that it has the same characteristics, but I cannot define a class, then create and/or modify instances. Logo gives more flexibility in working with the turtle object. Also, complex code is possible in Etoys, but it gets pretty ugly quickly (this could also be because I haven't been using Etoys nearly as long as I've programmed in other languages-- I'm sure Alan's Etoys code is much simpler than mine!). Then there are basic interface problems. A lot of people (children and adults) with whom I've worked have been very frustrated with the drag and drop tiles. The tiles don't drop where they want them to and create new scripts or fall into the wrong slot. . . the green square doesn't help them very much. It's also hard to know what to do when the environment is opened. My first impulse would not be to alt-left click an object to pull up a halo and then click the blue eyeball to pull up one object's viewer at a time. Everytime I explain this process, people just look at me or ask "And who came up with THAT?"
Squeak is powerful and flexible. I love working in it since I can easily do things that are difficult in Logo (especially since one cannot access the Lisp language underneath it in the commercial versions). Etoys is good for a number of activities such as simulations and animation, but in later versions of Squeak, it's been getting more bloated instead of more refined. Many more tiles have been added in and it's hard to navigate.
At this point, it might be good to take a step back and rethink how to do scripting in Squeak so that children can access the powerful ideas and flexibility of Smalltalk more simply. Just as Logo serves as a simplified Lisp, there could be a simplified Smalltalk for children to use. Ken raises some good points about using icons. The two could also be combined, as Alan stated.
Right now, there are tiles in Etoys and scripts have two sides: tiles and text. The text is simplified Squeak code and the tiles could easily be turned into icons, giving two modes of programming. But the larger part is to think about what primitives children need in the environment, and if they need all of them up front in a viewer, or if there can be layers of complexity added in. How can one transition from being an Etoys programmer to a Smalltalk programmer? Right now, the gap is rather wide, but ideally, the ceiling should be that high.
Anindita
Hi Anindita,
How can one transition from being an Etoys programmer to a Smalltalk programmer? Right now, the gap is rather wide, but ideally, the ceiling should be that high.
That's an excellent point and in fact what started the current effort towards Tweak. One of the primary reasons why the gap is as wide as it currently is, is simply that almost all of the useful notions we find in eToys are simply not present at the "system level". E.g., the gap is largely due to the fact that I can do things in two lines of eToys which would require me two-hundred lines of Smalltalk code and that I can do things in two lines of Smalltalk code which I can't do in eToys at all. This has severe implications on the learning curve since it essentially means that once you cross the line (in either direction) you can forget what you learned already and need to start essentially from scratch.
This issue of scalability has (as far as I can tell) never been addressed in any kind of authoring/scripting environment. You live either on one side of the fence or on the other and depending on which side you choose you can do certain things and not others. We are trying to address this problem in Tweak by coming from both sides; for one thing there _has_ to be an accessible end-user representation for all "system-level activities" (even though we build in some fences in order to prevent you from heavily damaging the system) and on the other hand, all of the powerful notions of the end-user domain are directly accessible on the system level.
It's also hard to know what to do when the environment is opened. My first impulse would not be to alt-left click an object to pull up a halo and then click the blue eyeball to pull up one object's viewer at a time.
So what would be your first impulse?
Etoys is good for a number of activities such as simulations and animation, but in later versions of Squeak, it's been getting more bloated instead of more refined. Many more tiles have been added in and it's hard to navigate.
This is a pretty natural effect of the scalability issues we see. If people had an easier way of finding "new things" and have them persist in the user interface the problem wouldn't even be half as bad. What needs to be done to sort this out is a better "meta authoring" environment in which it is easy to integrate the "things you need" into the user interface you use for authoring your projects.
At this point, it might be good to take a step back and rethink how to do scripting in Squeak so that children can access the powerful ideas and flexibility of Smalltalk more simply.
We have been working on this over the last two years and we are working on this right now. For example, we had a very interesting project with a group of design students to come up with alternative ways of scripting. Unfortunately, this project has no online presence which is a real shame considering how interesting the results were.
But here's something to look at which I think is pretty darn cool:
http://isgwww.cs.uni-magdeburg.de/games/start/jive.html http://isgwww.cs.uni-magdeburg.de/games/start/kindervorlesung_pics/kv_grins. jpg
It's in German (sorry for that but it has been made for German kids ;) and covers a lecture on "How to make Computer Games" which was given by my friend and collegue Maic Masuch (who is professor for computer games at the Univ. of Magdeburg) and who is very interested in scalable media environments for his students. The system you see there is called JIVE and has been done by Jana Hintze based on Croquet and Tweak.
Cheers, - Andreas
On Saturday, August 9, 2003, at 11:55 AM, Andreas Raab wrote:
This issue of scalability has (as far as I can tell) never been addressed in any kind of authoring/scripting environment. You live either on one side of the fence or on the other and depending on which side you choose you can do certain things and not others.
Actually, HyperCard (which I loved and in which I used to live most of my life) had a concept of UserLevels. You didn't actually need to write code until you got to the last level. You could do quite a lot without it and it turned a lot of non-developers into stack heads as they kept bumping up the level so they could make it that "little bit more cool".
Browsing or Level 1 Open, close, and browse stacks, search for text, click buttons, move between stacks, print, and save copies of stacks.
Typing or Level 2 Type, edit, style text, add and delete cards, compact stacks, set Arrow Keys in Text option.
Painting or Level 3 Create and edit graphics with the paint tools, set stack protection, edit icons, delete stacks, move between background and card layers, use the Power Keys.
Authoring or Level 4 Create, modify, and delete buttons, links, fields, cards, backgrounds, and stacks.
Scripting or Level 5 Write, edit, and debug scripts, set the Blind Typing option.
Hi --
What Andreas meant *starts* with the Hypercard Level 5 and works its way up to much deeper ideas. This is the part that hasn't yet been done well (or pretty much at all).
Cheers,
Alan
At 8:39 PM -0600 8/11/03, tblanchard@mac.com wrote:
On Saturday, August 9, 2003, at 11:55 AM, Andreas Raab wrote:
This issue of scalability has (as far as I can tell) never been addressed in any kind of authoring/scripting environment. You live either on one side of the fence or on the other and depending on which side you choose you can do certain things and not others.
Actually, HyperCard (which I loved and in which I used to live most of my life) had a concept of UserLevels. You didn't actually need to write code until you got to the last level. You could do quite a lot without it and it turned a lot of non-developers into stack heads as they kept bumping up the level so they could make it that "little bit more cool".
Browsing or Level 1 Open, close, and browse stacks, search for text, click buttons, move between stacks, print, and save copies of stacks.
Typing or Level 2 Type, edit, style text, add and delete cards, compact stacks, set Arrow Keys in Text option.
Painting or Level 3 Create and edit graphics with the paint tools, set stack protection, edit icons, delete stacks, move between background and card layers, use the Power Keys.
Authoring or Level 4 Create, modify, and delete buttons, links, fields, cards, backgrounds, and stacks.
Scripting or Level 5 Write, edit, and debug scripts, set the Blind Typing option.
Squeakland mailing list Squeakland@squeakland.org http://squeakland.org/mailman/listinfo/squeakland
--
Hi Anindita and Alan -
You both responded to my message using the word "icon". I think that word refers to a different set of ideas than those I'm trying to promote. Would you say that in Super Mario Brothers that Mario is an icon? That the mushrooms he eats are icons? I don't think that is how the players think about things. They are in a virtual world and a mushroom is an object in that world, not an icon that stands for something in the world. In games and in ToonTalk there is a suspension of disbelief that doesn't happen in iconic systems.
Alan brings up a very important topic - is the ideal system multi-modal so that users/programmers/players can switch between different ways of seeing and thinking about pieces of their program? Would it be best if they could easily switch between using pictures, English, demonstrations, and some precise notation (like math or Logo) on a fine-grained basis? I'd love to see more research on this but I'm not sure the result would be optimal. I'm afraid one might lose the simplicity of mono-modal systems. And in the case of ToonTalk I wouldn't want to introduce anything that interferes with the fantasy of being in a virtual world.
Best,
-ken
Hi Anindita --
As I said in my original email, the etoys were aimed at a very narrow experiment, range of children's ages and range of both subject and UI problems. So I would agree with many of the comments below. And some of the disagreements I have below are our own fault for not documenting well or widely enough. For example, the assertion:
At 11:55 AM -0400 8/9/03, Anindita wrote:
In Etoys, one cannot create a new class of objects-- just new instances of objects. I can create and program an object, then copy it so that it has the same characteristics, but I cannot define a class, then create and/or modify instances.
is much stronger than is the case. The object system in etoys is not the same as Squeak's (partly for good reason and partly for experiment). It's much more of a prototyping system and as such allows quite a bit of flexibility. The way to think of it is that the vanilla "Player" is like a class Object that just happens to know about graphics, etc. It would be easy to put a few more things in "Player" to make it fully general, but that was outside the particular experiment here.
Ditto "complex code". This was outside the experiment, but it really does limit older children's range.
All the stuff on the net was done via BJ-Conn's classroom, and she started her kids with a blank environment. If you don't want a blank environment, then just make one and store for children to start with. All the media stuff you mention in Squeak is there for just that purpose. Why complain about this when you can do something to help?
BTW, you can set a preference to have the halo of handles come up on mouseover: many teachers use this, some don't. There is balloon help on most things in the interface that is delayed one second so it doesn't get in the way of those who have become more expert. IOW, there are things you can do to deal with these problems. E.g. most of the many hundreds of children we've had experience with don't have any problems here, so I think it's more a style of approach that is affecting things.
I do think the tiles are a double-edged sword, especially on slower machines. I also think there are better ways to do this kind of scripting, especially when more elaborate expressions are desired. Here's a good opportunity to contribute to this opensource system. We've already gotten some good ideas from our colleagues at CMU's Alice project, who also have similar design goals and difficulties.
At 11:55 AM -0400 8/9/03, Anindita wrote:
At this point, it might be good to take a step back and rethink how to do scripting in Squeak so that children can access the powerful ideas and flexibility of Smalltalk more simply. Just as Logo serves as a simplified Lisp, there could be a simplified Smalltalk for children to use. Ken raises some good points about using icons. The two could also be combined, as Alan stated.
I think this is the right thing to do as well. We have been doing this quite deeply in the new (Tweak) system that Andreas Raab is making, and I'm hoping that the new (Scratch) system from MIT will shed light on all this as well.
At 11:55 AM -0400 8/9/03, Anindita wrote:
How can one transition from being an Etoys programmer to a Smalltalk programmer? Right now, the gap is rather wide, but ideally, the ceiling should be that high.
That is our favorite question. Let's all try to answer it in the most comprehensive and wide-perspective fashion possible.
Cheers,
Alan
------------
At 11:55 AM -0400 8/9/03, Anindita wrote:
I've worked with both Logo and Squeak and my research group has been having a lot of Logo/Squeak discussions lately. I'm with the Future of Learning Group at the MIT Media Lab, and recently I've had the great opportunity to work with John Maloney on Squeak after a year and a half of plowing through it on my own. I've also had a number of conversations with Seymour about Logo and Squeak.
My quick critique of Squeak is that there are a number of great things about it, but it doesn't meet its potential. It's completely object-oriented, allows children to program many different types of media and one of the biggest selling points for me-- it's open-source. It's free for schools to use and developers and teachers can make all sorts of modifications. This has been really helpful in projects that I've done. Logo is lacking here. I've mostly used Microworlds Logo or Imagine. What I find frustrating is that the only object is a turtle. This is great for the geometry microwold for which Logo was designed. It's a very elegant language and environment. But it isn't very extensible, either to different forms of media, or to communicating with hardware-- both of which are simple tasks in Squeak.
There are a few big problems with Etoys, however. The biggest one, in my opinion, is that it completely limits the object-orientedness of Squeak. In Etoys, one cannot create a new class of objects-- just new instances of objects. I can create and program an object, then copy it so that it has the same characteristics, but I cannot define a class, then create and/or modify instances. Logo gives more flexibility in working with the turtle object. Also, complex code is possible in Etoys, but it gets pretty ugly quickly (this could also be because I haven't been using Etoys nearly as long as I've programmed in other languages-- I'm sure Alan's Etoys code is much simpler than mine!). Then there are basic interface problems. A lot of people (children and adults) with whom I've worked have been very frustrated with the drag and drop tiles. The tiles don't drop where they want them to and create new scripts or fall into the wrong slot. . . the green square doesn't help them very much. It's also hard to know what to do when the environment is opened. My first impulse would not be to alt-left click an object to pull up a halo and then click the blue eyeball to pull up one object's viewer at a time. Everytime I explain this process, people just look at me or ask "And who came up with THAT?"
Squeak is powerful and flexible. I love working in it since I can easily do things that are difficult in Logo (especially since one cannot access the Lisp language underneath it in the commercial versions). Etoys is good for a number of activities such as simulations and animation, but in later versions of Squeak, it's been getting more bloated instead of more refined. Many more tiles have been added in and it's hard to navigate.
At this point, it might be good to take a step back and rethink how to do scripting in Squeak so that children can access the powerful ideas and flexibility of Smalltalk more simply. Just as Logo serves as a simplified Lisp, there could be a simplified Smalltalk for children to use. Ken raises some good points about using icons. The two could also be combined, as Alan stated.
Right now, there are tiles in Etoys and scripts have two sides: tiles and text. The text is simplified Squeak code and the tiles could easily be turned into icons, giving two modes of programming. But the larger part is to think about what primitives children need in the environment, and if they need all of them up front in a viewer, or if there can be layers of complexity added in. How can one transition from being an Etoys programmer to a Smalltalk programmer? Right now, the gap is rather wide, but ideally, the ceiling should be that high.
Anindita
--
squeakland@lists.squeakfoundation.org
-
Alan Kay -
Andreas Raab -
Anindita -
diegogomezdeck＠consultar.com -
Ken Kahn -
tblanchard＠mac.com