https://patapata.sourceforge.net/

>The PataPata project is/was an experiment focusing on taking ideas from Squeak and Self and moving them to Python, as well as trying to go beyond the ideas in a Pythonic and educational constructivist way.

>It also aspires to help people build microworlds and other learning tools for the Python platform, using a prototype-based programming approach.

>It is intended to mainly support "unschooling", "free schooling", and "informal" education.

>It has been previously discussed on the Python edusig list, although it now has its own mailing list on SourceForge here.

https://patapata.sourceforge.net/critique.html

>The biggest issue is that I learned that the seductive idea of prototypes may not be as powerful as its execution (especially as an add-on to an existing language). Consider what I wrote to someone else: "I've been repeatedly confronted with the fact that prototype languages are powerful and elegant but ultimately, like Forth, end up losing something related to documenting programmer intent. Documenting intent is one of the most important part of programming, and that is something that Smalltalk's formal class structure enforces for most code over Self, just like C's named variables document intent which gets lost manipulating Forth's data stack. Plus, it is hard for any great language feature to offset issues like lack of community or lack of comprehensive libraries."

>And after at person suggested you usually need to name things before you can share them, I replied: "And I agree on the issue of "naming" something in order to share it. Which gets back to the issue I mentioned of "documenting intent". With the PataPata system I made for Python, there was a choice point where I decided that prototypes used by other prototypes as parents needed to be named (a difference from Self). And I liked that choice. But then, what am I really gaining over Smalltalk (except not having a class side, which is nice, but is it worth the extra trouble and confusion?)"

>So, this leaves me questioning the whole move to prototypes. That person also pointed out previous work on "Exemplar based Smalltalk", so that is something I should look into further, perhaps as a compromise with Prototypes when I understand such previous work better.

[...]

I found some interesting email between Alan Kay and Guido van Rossum, in my archive of the OLPC educational software discussion group, where he hoped that the python community would make something like eToys. This is from a year after the last revision of PataPata's description, and I don't know if Alan was aware of PataPata. But I think "Snap!" (formerly BYOB) is the modern embodiment of what Alan was hoping for, based on JavaScript instead of Python. Python was (as Alan put it) "the general integrative base of XO", the focus and implementation language of the OLCP project.

https://snap.berkeley.edu

On Mar 9, 2007, at 17:26 , Guido van Rossum wrote:

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

On 3/9/07, Alan Kay <alan.kay@squeakland.org> wrote:

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.

Cheers,

Alan

On 21 June 2007 Alan Kay Wrote:

Well, objects need some machinery behind them. The machinery could be Squeak, or it could be Python, or JS, or ...

As I've mentioned in the past, on the OLPC, one of the ways that integration could have been done (and still could be done) would be to use something like X windows without frames to allow compositing of graphical front-ends of media objects.

A composited collection would be what Etoys calls a "project", etc. From this point of view everything is like a widget but could be made from different stuff,

From the object perspective all the graphical properties of the objects/"windows" are the same, but the back-end drivers for the phenomena could be rather different. This is "windows without windows", which is kind of what the OLPC really needs.

Also, since Squeak allows plugins, all of this could be done in Squeak, but I don't think that is the point here. I would rather see a richer better architecture using the chosen paradigm (e.g. Python) than do any "language wars".

But I will just gently say again that "Sugar can and should be a lot more integrated in its approach to dealing with many different kinds of media objects. They really need to be combined freely and not be bound to applications but should all be able to populate any "document" or "project".) Etoys uses one way to do this.

Cheers,

Alan

On 21 June 2007 Alan Kay Wrote:

Hi Eben --

Yes.

Etoys has external formats for its "documents", so they can be stored on servers, fetched, passed around, etc. We have tried 3 different approaches over the years (and all work currently). One of the approaches uses the Open Doc standard (where the scripts are in there as non-standard data). The format we are using now is a form of s-expressions (could be XML, but XML is really too verbose for the XO and for slow networks).

And, as I mentioned in the previous email, when on an XO itself, all the media objects could be integrated as collections of frame-less X-windows (or some similar but simpler mechanism).

Etoys (and, better, an improvement in Etoys that has more age range) could be done in Python by writing a parser for one of the file formats and making the Etoys graphical environment and control in Python. This would completely unify these ideas on the XO -- but something more like the integrated architecture for many kinds of media objects would still have to be created.

In other words, Etoys per se are not nearly as important as the ideas and access to authoring power for children that they implement.

In any case, we are gradually working on the next version of an Etoys like environment that deals much more richly with more of the important issues for children's authoring than we do now.

Cheers,

Alan

----

Here's a lot more about this stuff, and what we were doing with NeWS, HyperLook, and SimCity:

Alan Kay on “Should web browsers have stuck to being document viewers?” and a discussion of Smalltalk, HyperCard, NeWS, and HyperLook

https://donhopkins.medium.com/alan-kay-on-should-web-browser...