[sugar] Education?

Alan Kay alan.kay
Fri Mar 9 10:22:29 EST 2007

Guido knows that I've been advocating that the Python folks should do 
Etoys or a very Etoys like environment in Python (and that the rest 
of the OLPC be given an objectification and media and scripting 
integration that is Etoys like).

However, there are simply zillions of things left to be done 
everywhere for OLPC so the first round of SW on the XO will be more 
of a gathering of "suggestive" features and abilities (of which Etoys 
is just one). That seems fine to me.

Viewpoints Research (our little non-profit) doesn't have any "ego or 
identity" staked around whether the children's authoring environment 
is Python based or Squeak based. I have said many times that, if the 
general integrative base of XO is to be Python, then the Etoys-like 
authoring should be based in Python also.

However, I will personally fight to the death to make sure that there 
is a children's authoring environment that allows even young children 
to do simulation style programming with very rich media objects.

For now, that is Etoys. It could be a suitable object-oriented Logo 
with media objects (this is essentially what Etoys is). It could be 
some better design (let's do one). The base could be Javascript (if 
implemented on top of an integrated environment of sufficient power), 
Python (ditto), Ruby (ditto), etc. Whatever it is, it has to be above 
high thresholds, not a hack or a gesture.

Besides the programming the children use to learn important ideas in 
math and science, they also need to be able to see how their own 
computer world is structured by being able to "pop the hood" on 
practically everything they use. Perhaps it is OK for high school 
children to see the current code (but I don't think so). I think 
there needs to be a wrapping on the entire set of facilities that 
uses the same conventions that 9 year olds do their own programming 
in. Again, if it is to be Python, then it needs to be crafted a bit 
for younger children. E.g. Etoys allows easy unlimited parallel 
tasking, and this is very important for children's programming. Etc.

There are many good things that can be done here. We live in a 
computing world in which there is a tremendous amount of 
identification between many programmers and the tools they use -- so 
strong that it resembles religious fervor. From my view, ALL of the 
system have such flaws that we are better off being critical of all 
of them and try to use the best ideas from everywhere.

If "Children First!" is really the goal here, then we must spend most 
of our energies trying to make the childrens' environments more 
conducive to creative learning of powerful ideas.



At 02:52 AM 3/9/2007, MBurns wrote:
>On 3/8/07, no body <esorcus at hotmail.com> wrote:
>> >Isn't the mere presence of eToys on the XO a complete anathema to the
>>sugar philosophy?
>>As the XO is about education and etoys is the only software on the OLPC that
>>actually has any relation to education the above is a somewhat confusing
>>statement. But maybe I misunderstood and the XO is really about Python...
>I think the quote is referencing something else (though I may misunderstand).
>The eToys environment is a self-contained world of development. One
>that exists within the Sguar world of development. Programs, projects,
>source code and objects written in that eToys world do not exist
>outside in the Sugar world. You can write a sugar Activity or an eToys
>bundle, and, as we have seen in the gaming realm, they can often
>accomplish the same end goal.
>Now this may or may not be an issue to people(OLPC devs, students,
>teacers), they may or may not care, but it is an interesting 'world
>inside a world' for this transparent learning machine we are
>Michael Burns * Security Student
>NET * Oregon State University
>Sugar mailing list
>Sugar at laptop.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.laptop.org/pipermail/sugar/attachments/20070309/414e9e92/attachment-0001.html

More information about the Sugar-devel mailing list