[IAEP] scratch gone missing
bert at freudenbergs.de
Mon Nov 9 13:05:47 EST 2009
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
> 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
Here are a few examples of my own projects in the Squeak showcase that
I think would be hard to recreate in Scratch.
(objects with collision sensors adding their forces to influence
motion, this one is pure Etoys)
(adds a new Squeak class to simulate the pixel pattern of the XO's
(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:
> "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
> 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:
> 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
> 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:
> 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
- Bert -
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the IAEP