OLPC Visual Programming Language Discussion with Guido van Rossum and Alan Kay

This is a discussion from the OLPC Sugar mailing list, about implementing visual programming languages like eToys in Python.

From: Guido van Rossum
Subject: Etoys and integration

Isn't the mere presence of eToys on the XO a complete anathema to the sugar philosophy?

From: MBurns

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 Sugar 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 developing.

From: Alan Kay

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.



From: Guido van Rossum

Thanks Alan. I'm quite satisfied with this response and I agree with the priorities!