On 03.07.2009, at 18:01, Hilaire Fernandes wrote:

> Bert Freudenberg a écrit :
>
>> The Scratch team just made different design choices, they are not  
>> universally better or worse. I admire the clarity and ease-of-use of
>
> Obviously, but the net consequence is different user acceptability,  
> and as far as user acceptability means something, Scratch is better  
> in that field.
>
> Nevertheless, I share your feel about the Etoys way of doing things  
> which I largely prefer to the most constrained way of doing with  
> Scratch. But for average user, the constrained way of Scratch seems  
> to be better, probably the user stress is lower thanks to more  
> guided interface.

Agreed. Maybe a design wizard could come up with an interface both  
powerful and simple, but so far it looks like the two are in constant  
fight.

> If we want user to spend resources (time) learning and using Etoys,  
> the user should see an important benefice. I think Etoys should come  
> with more advanced artifacts to build really complex things very  
> simply (aka DrGeo for geometry, kedema for particle simulation, same  
> with electricity, and many more). Such complex artifacts could  
> interact to each other thanks to the Etoys scripting, then yes the  
> user could see really neat benefice worth the energy learning Etoys.
>
> The first step in this direction could be a fast bytecode package  
> loader, without the need to compile Smalltalk code.


Indeed. Perhaps you remember the discussions we had about  
ImageSegments that loaded classes complete with CompiledMethods? Which  
is way way faster than compiling code, and could not only be used to  
load squeak apps on top of a fixed image like for Dr Geo on Etoys, but  
could also lead to blazingly fast updates, or to very efficient field  
patches of deployed software. Maybe bringing this idea up in a  
separate thread here on squeak-dev would get some developer intrigued  
- I for one do find this a fascinating project.

- Bert -