[IAEP] scratch gone missing

Tomeu Vizoso tomeu at sugarlabs.org
Wed Nov 18 13:14:31 EST 2009

2009/11/9 Bill Kerr <billkerr at gmail.com>:
> On Tue, Nov 10, 2009 at 4:35 AM, Bert Freudenberg <bert at freudenbergs.de> wrote:
>> On 07.11.2009, at 23:28, Bill Kerr wrote:
>> On Sat, Nov 7, 2009 at 11:43 PM, Bert Freudenberg <bert at freudenbergs.de> wrote:
>>> On 07.11.2009, at 04:48, Bill Kerr wrote:
>>> > On Fri, Nov 6, 2009 at 11:35 PM, Tomeu Vizoso <tomeu at sugarlabs.org>
>>> > wrote:
>>> >> On Thu, Nov 5, 2009 at 11:10, Bill Kerr <billkerr at gmail.com> wrote:
>>> >> > http://activities.sugarlabs.org/en-US/sugar/browse/type:1/cat:107
>>> >> > How come scratch is no longer available for sugar?
>>> >> > (the link is to the programming category of sugar activities)
>>> >>
>>> >> You mean Scratch was available in ASLO but isn't any more?
>>> >>
>>> > No but it should be there since Scratch has a far better UI than Etoys
>>> Agreed on the "should be there" part.
>>> As for "better UI": Scratch does what it does incredibly well. If all
>>> you want to do can be done in Scratch then it is an excellent tool.
>>> Etoys is way more powerful, but comparatively hard to get into.
>> thanks for replying Bert
>> I'm not sure what you mean by Etoys being way more powerful. I would agree that Kedama, the parallel tile particle system, is way more powerful than anything in Scratch.
>> Did you have something more in mind?
>> Yes, too many to list all in fact. The power of Scratch lies in its limited scope - several years of development and refinement went into it to find the smallest set of features that make it easily teachable while still broadly applicable.
>> There are others who could describe the Squeak/Etoys philosophy better than me, but one of its core ideas is "no limits".
>> Where Scratch is a closed environment, Etoys provides just a thin layer of visual scripting on top of a much larger system. There are literally hundreds of objects that can be used as building blocks, from basic ones like rectangles, ellipses, polygons, or text, to complex ones like a book or a MIDI sequencer or video player or a working chess game (in Scratch there are only bitmap-sprites). In Etoys you can change coordinate systems, or embed objects into each other creating hierarchical animations, or connect objects with arrows to create diagrams that are fully scriptable, etc. In Scratch, every Sprite is separate, and they can communicate with others only by broadcasting - this is more limited but much easier to learn, and less prone to errors.
>> And if all that is not enough (there are always things the designers can't anticipate) Etoys lets you escape to the full Squeak environment. While Scratch is implemented in Squeak too, you cannot access it. Again that limitation was a conscious trade-off (for example it enables "players" for Scratch projects to be implemented in other languages).
>> Here are a few examples of my own projects in the Squeak showcase that I think would be hard to recreate in Scratch.
>> Collision Physics
>> http://squeakland.org/showcase/project.jsp?id=7052
>> (objects with collision sensors adding their forces to influence motion, this one is pure Etoys)
>> OLPC-XO-Display
>> http://squeakland.org/showcase/project.jsp?id=7050
>> (adds a new Squeak class to simulate the pixel pattern of the XO's display)
>> Euros
>> http://squeakland.org/showcase/project.jsp?id=7055
>> (connects to a web service to get currency conversion rate using a few lines of Squeak scripting)
>> For teachers the ability to make an easy start with a program is very important. When teaching a group then if several students encounter something they can't solve then it creates huge problems, especially for difficult to manage classes. And even for more advanced students features that are easy to find and work smoothly are important so that they can focus clearly on the challenging learning (scripting) rather than hunting around for where the tools are. There are a whole lot of features in Scratch that makes this possible (as you acknowledge). I haven't spelt out those features in detail here but will run some more tests and attempt to do so soon. One of my students mentions some of them here:
>> http://soeasyman123.blogspot.com/2009/11/great-race.html
>> "I found Etoys very troublesome for a few reasons.
>> 1. was because whenever I tried to save it would just close the program and I would jsut simply lose all my work. this occurred to me 3 times.
>> 2. I couldn't view the scripts while having the cars move because the scripts would get in the way of the test.
>> 3. the scripts were always in the way of the pictures so i had to close them everytime i finished with them which was very time consuming.
>> 4. the drawing tools on Etoys aren't the greatest tools you could get.
>> Although these reasons were troublesome I found Etoys interesting because there were so many scripts and other things to play with"
>> 1 sounds like a bug. 2 and 3 can be resolved by arranging the scripts so that the scripted objects only cover a smaller portion of the screen (like in Scratch).  4 is true, patches welcome ;)
>> One of the fundamental Etoys ideas is that "authoring is always on", hence there are no designated screen areas reserved for authoring tools. In fact, the tools cannot be used just on the user-created content, but on the tools themselves. This is a powerful idea in our opinion, it helps in demystifying the tools.
>> My inclination has been to try to transition students from scratch to python - but it doesn't work all that well I think in part because Scratch is *entirely* visual drag and drop tiles and the transition to text based programming is too abrupt for many.
>> There is a translation of Scratch into Python. It makes its tiles look almost like Python code, very cool:
>> http://mail.python.org/pipermail/edu-sig/2009-June/009382.html
>> It might work better with etoys if the intended transition was from etoys to smalltalk (squeak). That might be a better way to go but a harder sell in a school environment (since python is a better known language and also fits in with Sugar)
>> I think that GameMaker (proprietary but a free version is available) handles this issue best - it has drag and drop for beginners and a code window for more advanced and you can mix and match scripts using both features together. I know that etoys has a code window but I found it very difficult to use successfully.
>> You can have both tile scripts and textual scripts in Etoys, too. The difference is that there is no real need to use the textual scripting for the same stuff you can do with tiles. It's to access the advanced features, but you will have to know Squeak first to even know what to look for.
>>> OTOH
>>> Etoys does integrate into Sugar reasonably well, unlike Scratch. If
>>> platform conformity was the sole criterium for "better UI" then Etoys
>>> would win hands down, with its Journal and Collaboration support.
>> ok - with SoaS my efforts to enable collaboration on our school network have not been successful so although I have seen these features (in a session organised by Donna Benjamin in Melbourne a year ago) my students haven't been able to enjoy them unfortunately
>>> But another, maybe even more important difference is that Etoys is an
>>> open-source community project. So if there is an Etoys itch you know
>>> how to scratch (pun intended): patches welcome :)
>> Yes, I suspect this (the license) is the main issue which I raised with Mitch Resnick (and on this list) last year and wrote a blog summing it up:
>> http://billkerr2.blogspot.com/2008/11/scratch-license-disappointment.html
>> The last word in the comments on my blog comes from Tom Hofmann:
>> "Neither license is a free or open source license. The binary one limits modification, the source one limits use and redistribution. They're just unfree in different ways."
>> So I guess it's really up to the Scratch team at MIT to improve the license and their failure to do that has resulted in Sugar Labs downgrading its distribution perhaps not consciously but as a "slipping into darkness" event
>> Scratch is so enjoyable precisely because of being developed in a very small group, with lots of experimentation happening behind closed doors, but tight control of what gets released to the public. The license is just a consequence of not wanting to dilute the Scratch values.
>> - Bert -
> thanks for that Bert, much to think about there - I appreciate the thought and effort you put into your response

Btw, if anyone would like to work on improving the Scratch experience
for Sugar users (including making its installation easier) I will be
happy to provide pointers, help and contact the Scratch maintainers
and other people who want to see this happen.

I have heard that Scratch is quite used by Sugar users, and I'm
surprised at the little work that has gone into making their
experience better.



«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David

More information about the IAEP mailing list