Computers for children

[fanf]

I've been thinking about teaching children to program (or helping them to learn), especially since it came up in conversation at a recent party. (This is slightly inspired by my son, but he's only a year old so he won't be getting to grips with computers for some years yet.) The discussion at the party was based on our experience of starting with 1980s micros, which we think was a good way to learn programming, so how could we provide something similar to the children of today? I think this kind of micro must be:

* safe for playing with minimal supervision
* very simple (or apparently so)
* good for fun as well as for programming

More detailed requirements are a consequence of the above:

* The hardware has to be robust, so no moving parts. The drivers have to be robust too, so you can yank the power or plug/unplug peripherals without bad consequences.
* As cheap as possible, so it doesn't matter if it dies from abuse. This implies it should be off-the-shelf, and able to use standard peripherals, e.g. hand-me-down display etc.
* No high-level networking. Low level features are useful for older children to learn network programming, but for most usage it'll have an air gap for safety.
* No complicated user interface. It'll run one full-screen task at a time, such as a game or a programmer's read/eval/print loop.
* Easy to do fun things with graphics, sounds, and robotics.

I think the right solution is to use a "thin client": one of those computers that's designed to provide a keyboard and display to a remote server. You can get plausible ones for about £100. However, instead of booting off the net, it must be able to boot off flash (built-in or USB). At the moment a couple of good options are the TinyTuxBox 4 or the Linutop, both based on the same AMD Geode CPU, though the latter has the advantage of using LinuxBIOS.

It might not be easy or sensible to reflash the BIOS so that these computers can boot straight into BASIC for that authentic 1980s experience, so it's probably best to use USB flash drives as if they were Atari or Nintendo cartridges. Then it should be easy to ship software as disk images - with perhaps collections of games for fun as well as a programming language.

I'm not actually keen on BASIC as a language or environment. Its only surviving descendent is Visual BASIC which is too complicated, volatile, and proprietary for my purposes, and I don't see any advantage in resurrecting an older variant. Logo has plenty of teaching materials, which is handy, and it's a reasonably nice language with a fair amount of power. Or maybe Lua - though perhaps that only seems simple to people who already know how to program. I think it's also worth providing a text editor for programming, not just a command prompt, since we aren't constrained by memory in the way the eight-bits were, and the children will already have some familiarity with word processors.

Under the simple language and simple editor, it is unfortunately difficult to remain simple without expending a great deal of effort. It's a challenge just to get a modern CPU to run without toasting itself to a cinder. On the x86 platform you have 25 years of accumulated expedient hacks to work around in software. Doing general-purpose IO over USB is just a bit more complicated than a latch wired to your data bus. Given all that it seems that the most sensible plan is to start with a Linux or BSD kernel, and put a simplified userland on top.

It's difficult to choose how to support the key features - graphics for example. X11 is not simple, but it is very well supported and it's easy to make it look simple (if you throw away the display manager and window manager etc.) On the other hand it ought to be simple to build on top of the framebuffer device, but then (since I don't want to re-invent many wheels) I'd still end up pulling in layers of complexity (DirectFB and associated libraries) some of which are explicitly experimental and incomplete. But since it's all sitting on a Unix kernel I suppose I've already given up the idea of making its innards easily comprehensible.

Another example of the appearance of simplicity despite enormous amounts of hidden complexity has to be robotics. Phidgets look like fun hardware interfaces, but of course they depend on USB so they only appear to be simple...

Before signing off I should note that the OLPC XO is not what I'm after. It has more user interface and more networking than I want. I don't want a general-purpose computer, I want a programmable toy.

Comments

[kaet.livejournal.com]

I think it's worth concentrating on architecture-irrelevant and (to an expert) superficial aspects that could really affect adoption. For example,

• I think it would make sense to reduce the modularisation at some sacrifice of namespace integrity to not include abstract concepts not understood initially. (Eg no System. or OS. at the start of names; sound.play is okay, but System.io.print is bad). Blurring the distinction between programming-fundemental ideas like flow control and IO nonsense like sounds and the like is probably a good thing, initially.
  
• Minimal amount of typing necessary for the simple programs, taking into account things kids will want to do initially. No module headers, declarations, etc, needed before you can say "print 'hello world'".
  
• Making it easy to do amusing stupid things, daft noises, bright colours etc. Including silly dances in sets of robot movement primitives, etc.
  
• Tailoring defaults, and other niches where an arbitrary choice is to be made, to things which key in with developmental factors. For example, having high-bit character spaces occupied by sprite characters which are easily narrative (dragons, spaceships, etc), easy sprite manipulation, etc.
  
• Focusing on "emulating" (in the experience sense) simple machines which currently have a high status, eg the Nintendo DS. Simple, silly, games (like platformers) are still popular on those machines.
  
• etc
  

I think this kind of stuff might be good (for someone) to focus on from the start. Also, it might be worth talking to 1ngi about this kind of thing, as she's probably got very relevant skills.

[fanf]

Thanks for that - all very good suggestions.

[pm215]

Making it easy to do amusing stupid things

I'm reminded of the OpenGL function glutSolidTeapot()...