Summary
Two days ago, Alan Kay gave a very inspiring keynote here at EuroPython. I can't possibly do it justice but I want to describe it anyway.
Advertisement
Alan was still recovering from a recent bout of pneumonia, so instead of delivering the presentation in person, he talked to us from his living room in California over a video link provided by CERN. It was one of the best video presentations I've ever seen -- delivered in person it would have been even more stunning.
The entire presentation (slides and interactive demos) was done as a Squeak program, although I'm not sure about the details. I believe that the entire thing was running in a browser plugin -- quite an amazing feat if you ask me! http://www.squeakland.org has more info about the plugin.
Alan's subject was "Children First". He started out by telling some anecdotes about how children can learn math without realizing it. For example, a project for 6-year olds involved taking a shape and increasing its size by repeating the basic shape. Then they are asked to count how many squares they added; then do it again. By tabulating the results they (at least the smart ones) discover that the deltas form a series of consecutive odd numbers, and the sums form a series of squares. The amazing thing is that the whole project is presented as a kind of art project, not as a math class!
Alan then dove into a demo of the capabilities of Squeak. Turtle graphics are nice, but the more interesting property is of course that you can "open" any object, which shows a menu that lets you apply a wide range of commands to it, including a script that can make it move, respond to events or other objects, and so on. Great hilarity when Alan demonstrated that not only can we let any object on the screen start rotating, but you can recursively open the menu itself and make it rotate!
Back to a kids' science project: studying gravity, and repeating Galileo's experiment. Kids (this time about 10-11 years old I believe) climb a garage and attempt to measure with a stopwatch how long various objects take to fall. One girl comes up with the big idea: drop two objects simultaneously, which makes comparison much simpler. Kids are scientists!
And back to squeak -- using frames from a video recording of a ball falling, kids develop a program that helps them discover or verify the formula for speed under constant acceleration.
Other experiments that Alan showed (everything still running live in his browser!) included a simulation of ants discovering food, dropping feromones and following the trails, and more stuff that I can't remember right now.
Alan also talked about the $100 laptop project; he is on the OLPC advisory board. Apparently Python is specifically involved. There was little Python content to Alan's talk, which is fine by me -- Keynotes like this one are supposed to challenge or tickle the audience, not necessarily to confirm their world view. Alan did end by expressing the hope that a system like he demonstrated will be implemented in Python; apparently (or just for the occasion :-) Alan believes that Python has a much larger mindshare than Smalltalk or Squeak, and that because of this a similar environment in Python will have a greater chance of succeeding than the current Squeak one. Also, the $100 laptop already has Python, and Alan is of course hoping that a Squeak-like environment will be part of it, so this appears expedient. (At the Shuttleworth summit in April I believe Alan also suggested that Squeak is suffering from its extremely simple graphics model; apparently it cannot benefit from graphics accelerator cards because of its platform-independent architecture. [Update: this is incorrect, see responses below.] Python on the other hand already has bindings to OpenGL and DirectX, for example.)
In conclusion, Alan's talk was extremely inspiring to many of the attendees (including myself). Alan's primary message, "Children First", will ring true throughout the Python community.
The big, big, big problem with getting kids to code is language: not computer language, but human language. My children are Dutch, and they can only start to code using English-based languages like Python and SmallTalk when they're twelve years or old or so: the programming languages themselves pose to great a challenge vocabulary-wise at an earlier age.
I did try to translate Squeek into Dutch, since it seemed to give them the best chance at coding something fun, but was hampered by the fact that I didn't understand the environment myself, to begin with, and thus didn't manage to discover where to begin the translation.
I'm not sure about solutions: certainly, the Dutch translation of Excel basic isn't among the candidates, but equally, initialize_graphics_context() or advance_sprite() isn't going to work for six-year old kids. And logo simply stops being fun to hack after an hour or so: the resulting programs don't have any interactivity.
I know I learned English from Sinclair Basic, mainly, when I was twelve, but then, I was given a ZX-Spectrum by my parents in the hope that it'd work wonders for my English, and I was twelve already.
I don't know what was said about Squeak and graphics performance, but it's certainly capable of using OpenGL bindings and with that take advantage of HW acceleration. OpenCroquet (http://www.opencroquet.org/) is an immersive 3D environment (among other things) and it's written solely in Squeak. (You can also search Google Video for "Alan Kay" or "Croquet" to get video demos).
Oops, seems I was misinformed or misinterpreted what I though I heard. (Nothing was said in Alan's keynote BTW.)
I did get a personal demo of Croquet by the nice folks at qwaq.com in Palo Alto. I did get the impression that it was kind of slow, but I have no idea what could cause that.
As you may know, "Squeak as a Smalltalk system" and "eToys on top of Squeak" are different things. EToys provides a graphical tile-based scripting system in which the kids can write a program by dragging-and-dropping and combining the tiles, or fragments of program. The label on the tiles as well as the other phrases in the environment can be translated easily. In fact, eToys has been translated to handful natural languages and kids (some are really young) have been using it in many areas in the world. What Alan showed in his talk was this eToys environment.
... That said, unfortunately, we don't have Dutch translation of eToys yet. We'd be more than happy to add it to eToys distribution. The "language editor" tool that lets you add the translations to the phrases is in the Squeak (Squeakland) distribution; it is possible to translate without knowning much of Squeak. But, sorry for not providing enough documents and support.
In regards to Logo and "fun"... One of the points Alan made in the keynote was that there are things universal across the all human cultures, and there are non-universals. The universal stuff include painting pictures and making stories, and etc., and these things can be "learned" by kids automatically. The non-universal things, such as science, abstract math, etc. needed to be invented and have to be taught carefully. If we facilitate the environment so that kids can have "fun" with non-universal topics, it is really great. Logo (while some implementations do lack interactivity) still can be used in such situation. Yes, it should be fun for kids, but can be "hard-fun".
> The big, big, big problem with getting kids to code is > language: not computer language, but human language. My > children are Dutch...the programming > languages themselves pose to great a challenge > vocabulary-wise at an earlier age.
> Alan did end by expressing the hope that a system like he demonstrated > will be implemented in Python [...]
If there's anyone else attending the EuroPython sprints who wants to bounce ideas around about this, I'll be around until the end of the post-conference sprints. I'm currently sitting in the MoinMoin sprint room, but may move between rooms tomorrow and on Saturday.
Thanks for the nice comments. Here a few clarifications. I showed examples of children doing real math and real science when put in environments that foster these new kinds of thinking (including especially designed computer authoring environments that are like an object-oriented Hypercard for children).
We have had good results over the last 10 years with one of these (called Squeak Etoys)which has features that allow it to be localized to many different languages, used as a "WYSIwiki" on the web, and to dynamically share in real-time for mentoring and collaboration.
The next wave of projects in the 3rd world will be large enough to create real problems in distribution, localization, maintenance, extensions, etc. I think that the more widely established open source communities (like Python and Ruby) are better set up to provide the large number of programmers needed to help spread these ideas by the millions. Neither Python, nor Ruby, currently has a children's environment, and the poor quality of the DOM in the browsers means that it will be a very long time before a children's environment as good as Squeak Etoys will be built there.
However, since our new file format uses OpenDoc (with code hidden) the "player/authoring" kernel plugin for this content could well be written in Python or Ruby. And this would make things much better for the children of the world for the above reasons.
BTW, Squeak does have a very good foreign function interface, and we do use OpenGl, etc., heavily in our Croquet system. So I'm not suggesting that Python be used because of something that Squeak can't do (and has obviously already done). I'm suggesting this because I'd like to see the dominant communities in open source get interested in children and to start from current best practices.
> The big, big, big problem with getting kids to code > is language: not computer language, but human language.
-A- Programming is at first much nearer to mathematics than to a native language.
Mathematics is in essence a universal language that makes efficient use of letters, lettercases and diverse variants of the alphabet. Think of A, B, C and a, b, c and those signs for alpha, beta and gamma to describe anything basic in terms of a triangle.
Those seemingly english terms that are recycled with any next programming language act as signs that are linked in immediate mode to (hopefully) an easy an clear understanding. They do not act as native language words whose meaning is relative to other words and phrases that provide context.
Any transfer of those 'if's and 'for's into a local non-english language is like asking for a german version of mathematics.
A programming language:
if (......) { .......; ...; } else if (....) { .............; }
Another programming language (requiring in total and on purpose only a most small mental footprint, while offering a freedom of choice regarding the mix of programming paradigms )
if ......: ....... ... elif ....: .............
User(child)-defined names might(will) use local-language wording. With this necessity for naming entities in software we lose the immediate mode quality of understanding because of introducing meaning dependent of context. This highlights the real 'adaptation-to-the-mind' problem of any source of application software. This is independent of whether the thinking mind is a child, a teenager or an adult. And independent of any programming language of course.
-B- Python's footprint in the real world is hopefully still growing. To give this growth a most significant boost we should sooner or later be able to switch from JavaScript to Python to make the web document inside a browser dynamic (wishful thinking or not - if I may ask ??).
Alan Kay at CERN was an emotional experience. Another - let's say: most strategic - option for Python: this $100 computer-tool with Python itself as battery included. Because compared to the current situation Python as battery would scale very well from a learning to a problem-solving tool for real world needs.
I am sure a lot of Pythonistas would give it a serious thought to contribute to the 'Children first' project. But how to get this started ... of course this effort requires a leading force and this needs funding ... now quoting the front side of my free EuroPython 2006 t-shirt which just says: "Google", the back side reads:
Python: programming the way Guido indented it
Why not another extension day of EuroPython 2006 this autumn aimed at starting up this project and helping developers moving into distributed open source space that have no former experience with such work ?
PS Small world: on returning from Geneva I found the finalization of a bookorder that has slept for quite a few months at last in my postbox: a publication from 2001 titled "GUI Programming with Python using the Qt Toolkit" by Boudewijn Rempt.
Here in Brazil we speak portuguese and all universities and almost any place where you learn programming logic you start by using (or at least have contact with) some form o portugol, that is a language with everything in portuguese. They always talk that it is something like pascal, but as you don't use ; on the end of lines and sometimes don't need to declare variables nor mark blocks (using only indentation to do so) I tend to think that it is more like a very limited subset of python. All the reserved words on python and all the api are using english words, they are not using greek letters and signs, so don't say that it is the same as asking for german math.
> If we > facilitate the environment so that kids can have "fun" > with non-universal topics, it is really great. Logo (while > some implementations do lack interactivity) still can be > used in such situation. Yes, it should be fun for kids, > but can be "hard-fun".
I wonder a little about this Montessori approach. One can couple certain abstractions to sensual experiences but I personally prefer about formal stuff a certain decoupling and self-referential "abstract imagination" as Emmy Noether might have put it. Friendly simulacra as a silver bullet? This will to unify reality with illusion spectacle in an infite sensual screen seems to be our own prime consumerist phantasy - a post oedipal realm of non-detachment. Not passing the mirror but stay in front of the presentation and play with the buttons.
The possible next step after becoming bored might be simulating bugs and breaking the illusion of causality within the Sim to enhance its effect of reality. When Python joins the enterprise of turning everything and ourselves into toys I promise to contribute a real bug. This will be "easy-fun".
These lines of source require as context a def statement:
def something_in_portuguese(...):
I refer to 'def', 'return' and 'yield' as 'signs', which should not be translated to a local language to aid "Children First".
The 'immediate mode' for an easy and clear understanding that should be enabled by these 'signs' is naturally not available at first. Any younger (or older) mind to enter the programming space must think hard to build up a valid understanding what is the substance of a 'def', a 'return' or a 'yield'. This thinking hard and discussing lively with other minds of course takes place in portuguese.
After having fought building up the (hopefully) easy and clear understanding for yourself you can shortcut this to the related sign - for instance this english token 'yield'.
This is the 'immediate mode' I was talking about and which gives any programming task "Rückenwind" [for a translation into english look here: http://dict.tu-chemnitz.de/].
PS Python shines with some of its keywords alone - 'elif' is born as a sign (what's the point to use 'else if' or 'elseif' instead ?), 'def' defines a function or a method avoiding the unbalanced 'function'.
Hi Alan, you wrote: > I showed examples of children doing real math and real science when put in environments that foster these new kinds of thinking...
I'd put a focus on "experiments first" viewing children as a group with most active experimentation habits. Kids (as well as many adults, especially artists) can not compute. Their way of computing is experimentation. Which includes: the generation of objects to experiment on, making the runs, observing the results, and making (informal) generalization. BTW, that looks like a way of modeling reality by living creatures that provides the necessary (for success) *prediction* capabilities. That's how they are doing their science, meaning a way to estimate a result of new experiments based on old ones.
Recently i was impressed with my (blue merle) dog Stepa (18 mo) modeling skills: in few minutes he discovered the Snellius law (incident angle is equal to reflection angle) when i was bouncing a ball off the wall. In 2-3 trials (-and-errors) directly chasing the ball, he learned to wait-a-second and intercept the ball reflected off the wall; he precisely "computed" the trajectory of the reflected ball and visibly enjoyed the discovery. Same kind of impressive experimentation/learning skills by my grandson Grisha (20 mo): every minute of non-sleeping time is a hands-on experimentation - second to nothing in terms of intesity and variety of experimentation.
So to me, it is less about Python or Ruby, and more about "new" computing paradigm - computing by experimentation. I found a wonderful paper by Nick Metropolis, "The Beginning of the Monte Carlo Method," Los Alamos Science, No. 15, Page 125, 1987 http://lib-www.lanl.gov/la-pubs/00326866.pdf , an amazing history of ideas by the founders of electronic computing era (Enrico Fermi, Stan Ulam, Nick Metropolis, John von Neumann, Dick Feynman), the 5 pages worth of many books. In particular, Nick Metropolis tells about the idea of "electronic experimentation", introduces the "experimental mathematics", tells a nice story about a mechanical trolley E.Fermi invented and used to "compute" neutron diffusion in the nuclear reactor (1943 - later they called it "Fermiac"). Then, they viewed the first coming to them electronic computer (Eniac and then Maniac) as a fast electronic experimentation (vs. fast calculating) device. [In other paper by Nick M. there is a scanned printout (with hand-written notes) of E.Fermi' machine-code program ("hex2dec" converter and printer).] They looked at electronic experimentation as a way to handle/compute complex problems when no formal equations are available, only the (physics) guesses.
Those great ideas bring us to the new vision of non-computational use of computers, computer architectures for experimentation, and a joyful (vs. painful) programming paradigm based on experiments with dynamic (silicon) objects. Which includes the generation of proper events/objects, letting them to evolve in space and in time, and then measuring and *generalizing* programmatically the results of the experiments. Which completes the programming phase and creates the input/output mapping, a sort of experiments-structured memory suitable for problem solving by *search* using a *new* input. Is this a kind of experiments-driven "indexing" of a specific application domain and then using the experiments-structured memory in a search mode to reason about new inputs (problems)? An experiments-driven google for kids, dogs, and politicians? best, val
Previous Topic
