[IAEP] scratch gone missing

[Bert Freudenberg]

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 -

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/iaep/attachments/20091109/766bd399/attachment-0001.htm