[IAEP] scratch gone missing

[Bill Kerr]

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

- Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/iaep/attachments/20091110/b75b9933/attachment.htm