<html> <body> At 01:23 PM 12/19/2006, Andrew Clunis wrote: <blockquote type=cite class=cite cite="">For the really early years, programming should probably be squeak's job. :) </blockquote> I think of a programming language as partly a UI design and partly as a semantic design. Different ages of children need different kinds of things in their UIs, and this includes what a program looks like. I think of the surface syntax and the appearance of a language as being derived from (that is, a view of) an abstract syntax that expresses and connects to the semantics. This allows the possibility of having a number of surface appearances for different purposes (such as dealing with the different needs of children at different ages). OLPC is being set up as a Python machine, not a Squeak machine (and that is fine with me). If so, then I think a UI for elementary aged children that allows Logo-like and Etoy-like scripting and "Model T" control of media objects is very important. Right now Etoys is serving as this UI and functionality, but it is drawing its view of scripting from Squeak Smalltalk, not Python. A more ideal direction and goal would be to think of Python semantics as the eventual target, and think about what scripting for a 7 year might look like (it will be different in important respects from the current `Python conventions). I'm just trying to nudge things towards thinking about "Children First!", so that we can gradually get to an environment that is both rich and explorable by most of the ages of children we are trying to serve. Cheers, Alan --------------- At 01:23 PM 12/19/2006, Andrew Clunis wrote: <blockquote type=cite class=cite cite="">-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, Dec 19, 2006 at 08:41:12AM -0800, Alan Kay wrote: > Hi Andrew -- > > I guess I agree with what you say about Python and its structure, but > I was thinking much more about what the children see, not so much the > developers. That brings up another problem.  I myself was a child not so long ago, and as I started to become interested in computer programming and software development, it was important to me that I was "on the same level" as all other desktop application developers (I admit that I was a bit of a weirdo, though). Later on, in Grade 11 "Computer Engineering" class, we received instruction on "Turing", a toy language with a toy interpreter.  It was proprietary software, only ran on Microsoft platforms, and couldn't interact much with the host platform (beyond poking bits on I/O ports). What I mean to say is, if these mechanisms are not the true native face of the system, they will never be more than a toy (a notable consequence of this is that developers won't eat their own dog food). > > Since this is a children's machine, important aspects of it should be > deconstructable, and in terms that are as simple, understandable and > useable as possible. So, if the child "pops the hood" on some > interesting object they've been playing with, they should see (I > claim) a "Model T" version of the properties and behavior rather than > the "fuel injected Ferrari" that might be underneath. And they should > be able to write useful scripts in those terms. Why not just expose the same API for everybody?  No one is obliged to use the more complicated functions if they don't need them.  Besides, keeping beginner hackers in mind is a good way to keep our APIs sane and pretty. > > For example, the movie player can be abstracted as the very same kind > of animations that the child can make and script, and the movie > player UI can be constructed in those terms. Much can be done with > such an approach, and the special stuff that is being done wrt movies > (MPEG decoding, file reading, other optimizations) can be left until later. It would be awesome if Develop activity did attempt to expose some of as "Supplies" in a graphical fashion; giving users a graphical list of tools to select from (that would equate to Python packages). Unfortunately, we can't get anything more granular than that. > And, e.g. any objects that have graphic properties can be presented > in as similar ways as possible, regardless of how they were actually > written underneath ... > > And, I think that the wrappings and views shown older children can > look more like Python than those suitable for the younger ones ... For the really early years, programming should probably be squeak's job. :) > > Etc. > > Cheers, > > Alan > - -- Regards, Andrew Clunis -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFFiFhRALkUMXSNow8RAizjAKCmgXuwmHVzC6W6f8ZmwWLXxNpewACgmB4p a1vkeWKKotnHI8LqJIsNup0= =YN4W -----END PGP SIGNATURE-----</blockquote></body> </html>