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 that Lua well may be worth thinking about. It reminds me of being the new (clean) PHP, and that's something which non-programmers took to very easily. When I think of the books I learnt from, they had chapters on conditionals, loops, arrays, and so on, and that seems to be easily doable for Lua. What it lacks, though, is a rich, appealing IO layer. Like mode seven on the beeb, and all the stuff you can do with the C0 controls. I think you need a thick library without too much abstraction, so that you can get brightly coloured things on the screen, and annoying noises out of the speaker, quickly.

Aren't you missing a trick, here, though? It's now so easy, again, to build computers, just like it was in the early days! And the possibility of a machine with an open "ROM" and hardware, how wonderful that would be!

[gerald_duck]

Logo is a language eight year olds can be taught very comfortably. Smart children would probably be entirely happy with it sooner, and I've personally managed to teach fairly bright nine year olds rudimentary recursion in half an hour using Logo before now.

Why not an OLPC XO? It has more things than you want, but surely that's much better than fewer, given you can fairly easily disable stuff? It's also cheap and rugged.

Another possibility might be Lego Mindstorms? Or an old BBC micro with the Logo ROM inserted higher than BASIC?

How easy would LISP be to learn? It goes against the grain of a lot of more recent syntax, but that's not necessarily a problem if it's the first language someone encounters.

Or you could try Alligator Eggs, though it feels a bit contrived to me, and not actually as easy to understand as lambda calculus.

[fanf]

I think whatever language I pick I'd have to spend some time plugging it in to a graphics library (e.g. Cairo), sound, etc. I wonder if it's worth plugging in a terminal emulator so you could type somthing like VDU 27,91,51,49,109 to get red text. (An evil way to do this would be to run in xterm and use the WINDOWID environment variable to draw graphics in xterm's window, like w3m.)

I don't want to make a computer from scratch because it would not be sufficiently robust or cheap. Something based on off-the-shelf hardware is more likely to be of use to other people.

[simont]

I think it's also worth providing a text editor for programming, not just a command prompt

And conversely, I think it's definitely worth providing a command prompt, not just a text editor!

The thing I always thought was really good about BASIC was the interactive command-by-command mode, which enabled lots of hands-on playing with the capabilities of the system before you started organising your commands into list form. Lots of round-trips during one's interaction with the machine allow you to get lots of information: typing in a twenty-line program, hitting Run and getting a single piece of information back about whether it worked or not isn't nearly as illuminating as trying several of those lines one at a time in rapid succession and then stitching them together into a program.

So this was a big plus point of BASIC as a teaching language over, say, Pascal; if it were me choosing a teaching language now I'd probably make that a major criterion in my choice.

[fanf]

It seems a bit of a shame to get an OLPC XO and then lobotomise it. They're also more expensive than thin client hardware, given the buy-two-get-one donation model.

Lego Mindstorms makes a plausible peripheral, but it's a satellite to a bigger computer. A good alternative to the Phidgets, I think.

An old BBC doesn't have any sensible storage options.

Lisp is just Logo with more (). Alligator Eggs is a game, not a programming language.

[hairyears.livejournal.com]

Maybe Pascal is the place to start, although Object Pascal isn't all that good a progression to more modern programming practice.

An interesting question: what would you use to teach someone programming?

[fanf]

Indeed! Logo and Lua also have command prompts.

The BBC Master had a text editor in ROM. You could switch from the command prompt to the editor with *EDIT, and it would present you with the current program to mangle as you wished, and it would be re-tokenized by BASIC when you exited. I'd like to have something like this, though I'm not sure how it would work in a modular language like Lua, or a working-image language like Logo.

[kaet.livejournal.com]

I see your point about the home-build machines. I think it would be a pity, though, as it gives you a real handle on what's hapenning when you encounter, for example, references and pointers, to be aware of the address bus, data bus, and so on.

Perhaps what we're after is a programmable virtual machine which could be hosted/emulated/developed on any machine, and then reunited with some well-designed hardware? Even going as far as it having an explicit assembler, would help, I think (underneath the proper language). I'm thinking of addressing modes, stacks, and so on, again, for advanced children, which no one need deal with per-se any more, but is a brilliant background for when encountering issues like "call by...", virtual addressing, cloning/referencing, etc.

[kaet.livejournal.com]

I learnt LISP as my first language (a "sideways" ROM on an Electron) and found its syntax confusing once I'd discovered other languages (such as BASIC) were simpler. On the other hand, I put the effort into learning LISP because it looked fun and bizarre, whereas BASIC just looked (as it was) like a long list of instructions.

[fanf]

Not Pascal, because it's too static, both in terms of its edit/compile/run/crash cycle and itsstring and array semantics. As I said above, Logo or perhaps Lua seem like good choices. Both are quite simple (though still powerful), dynamic, interactive. Do you prefer functional or imperative? (Though Logo is dynamically scoped so isn't properly functional.)

[fanf]

I think something like that would be good for later on, once the child has got the basic idea. I wonder if the current Mindstorms platform is suitable - though perhaps even that is too complicated given that it has USB and Bluetooth and two CPUs (8 bit microcontroller and 32 bit ARM).

[ronebofh.livejournal.com]

boutell was talking about programming for kids on his journal not too long ago.

[pjc50.livejournal.com]

Various people I know have been looking at this: Alastair Turnbull + Tom Lynn (Nifki: web-embedded simple dev environment) and Eben Upton (the "sub $10 computer": basically an ATMEL with a video out and Lua ROM)

[pjc50.livejournal.com]

Actually, why not a real BBC master?

[fanf]

Thanks for the link!

[fanf]

You can't sensbly plug old computers into modern storage.

Thanks for the pointers. I explicitly do not want anythinger that runs on a big computer, especially not something webby. It's too unsafe, and more difficult to convince the child that they can make something as good as anything else on the system.

[fanf]

Do you have a link to Eben Upton's project?

[bens_dad]

The hardware has to be robust, so no moving parts
Which aspects of programming are you thinking of teaching ? What age child ?

I would have thought that children would learn from programmable robots earlier than a keyboard/mouse/screen computer.

As well as LEGO mind-storm, I'm thinking of the Logo Turtle and perhaps Big Trak (though it was probably too expensive). Did you know that programmable robots go back at least to the ancients Greeks (see New Scientist, 04 July 2007, issue 2611 "The programmable robot of ancient Greece" - http://technology.newscientist.com/channel/tech/mg19526111.600-the-programmable-robot-of-ancient-greece.html
if you have access) ?

[ewx.livejournal.com]

I though that the Lua book was pretty good as programming language books went (albeit with lots of prior experience). I've yet to find a task that made me think "I'll write it in Lua" though...

[fanf]

The idea is for it to be the first general-purpose programming language. Good idea that something like a Big Trak would be a good toy to precede this one. (You can indeed use Mindstorms in that way as well as hung off a computer.) As for age range, starting from as soon as they have enough literacy and numeracy - 8 is a commonly-cited starting age. Before programming, a simplified computer like this would be good for running games and puzzles and tutorial software. It might even be useful at pre-school age for helping to learn letters and numbers - though books are better :-)

[covertmusic.livejournal.com]

Squeak?

[pjc50.livejournal.com]

I briefly considered wiring an MP3 player/recorder to the BBC tape interface, but then I found
http://web.inter.nl.net/users/J.Kortink/home/hardware/gommc/what.htm (might not count as "sensible" :)

How useful is it to plug old computers into modern storage? So long as it has some suitable convenient stuff of its own...

How about the Amiga 500? Archimedes? Both have graphical WIMP interfaces, are reasonably programmable (albeit in BASIC), have hardware manuals which aren't too heavy, and use floppies for removable storage (although they aren't terribly durable and not easy to write from a regular PC)

If you go for the Linux PC approach maybe run some sort of VM/emulator on it to pretend that the system is simple? Although that will result in a "matrix" moment when the kid realises what's actually going on.

I'll ask Eben about his thing, I don't think it's on the web yet as it's not finished.

[kaet.livejournal.com]

That makes sense, though I remember that a lot of people had started to fiddle with assembler by the time they were nine or ten, so it's not that much later on, :).

[kaet.livejournal.com]

I agree with that about Lua. It's very much an "oh, alright" type of language. Which I think is good in situations like embedded scripting and with devices like Tony's, where the choice is limited, in practice: bland is good, :).

[sbp.livejournal.com]

Pity the Sharp Zaurus series of machines isn't more widespread. They run Linux but the OS is flashable. You could use the CF slot as a pseudo-cartridge/ROM slot, they have a serial port, some have USB hosts, and some are clamshell-design. They'd probably be good for small fingers too.

Or you build on top of a portable gaming platform that kids are already using or might want to use for gaming, so they wouldn't have to buy extra hardware.

[fanf]

I have a half-written scriptable sftp client. I wanted a scripting language which could work as a declarative configuration language for an rdist replacement, but less bonkers for variables and tables than Tcl.

[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]

1980s storage was really shit. I want to bring back the good bits, not the bad ones. Children have to be able to save their work in a useful and reliable way, which implies modern storage and/or networking. As for the Amiga and Archimedes, I want neither floppies (obsolete) nor WIMP (complicated).

I don't think virtual simplicity has much of an advantage over a simplified kiosk-style userland. However I'm not sure if gradually revealing more and more layers of Unix complexity will be fun or overwhelming. I wonder if something like Lego Mindstorms can be the small entirely-comprehensible computer, or if that's too much of a cop-out. Dunno.

[fanf]

Yeah, that kind of hardware is worth keeping in mind, though for my purposes you have to be able to plug in a keyboard (even via Bluetooth, at a push). The simplified Linux userland strategy has the advantage of being pretty portable, unlike something that aims for low-level simplicity...

[fanf]

Thanks for that - all very good suggestions.

[fanf]

TBH, I'm not a great believer in OO or graphical programming. Squeak strikes me as too complicated and unrealistically twee. But I'm willing to try it out on real kids :-)

[cartesiandaemon.livejournal.com]

I just came across lua recently. It seemed very easy to get up to speed with. Eg. has a good mix of types and casting.

But object variables are by default *references* which is quite elegant, but possibly confusing when you're first introduced to them...

[hairyears.livejournal.com]

I know of no good or even passable programming language for teaching the basic principles and best practice of our craft. This may reflect the fact that I have such a poor academic background; I am certainly no teacher and, being largely self-taught, I suspect that I would be terrible at it.

Nevertheless, there have been three attempts at teaching me programming, starting with BBC Basic in an ad-hoc after-school programme: I 'mastered' Basic very quickly, more through my own exploration that a decidedly undemanding and unispiring selection of teaching texts. However, I rapidly tired of the limitations of the language and it seemed that there was very little I could do with my new-found knowledge; worst of all, there seemed to be no obvious progression between Basic and the 'real' world of compiled code for commercial applications.

Nevertheless, this elementary training served me well when, as a student civil engineer, I used Casio Basic in bringing the digital world to the construction site. Note, however, that I effectively started from scratch on VBA in MS-Access: it seemed that nothing I had learnt on earlier forms of Basic was remotely recognisable.

My second introduction was FORTRAN-77; I found it very easy to pick up, as did my classmates. Admittedly, we were all engineering undergraduates, numerate, skilled in algebra, and technically-minded. We did very little text-handling, and I doubt that we could (or should) have explored that, but Fortran proved to be a very effective teaching tool. The question is whether it is still relevant, and whether more modern programming techniques can be implemented in it - or, indeed, whether you could teach a child Fortran, as they would lack an existing background knowledge of algebra and mechanics.

Third time 'round, and DeMontfort University had a two-pronged approach: start with elementary programming in Modula-2 (a derivative of PASCAL, with support for libraries), and progress to an advanced language (C++) while using SmallTalk to teach the principles of Object-Oriented programming. In theory, this is the correct approach: you would no more start someone off on C++ than take a learner driver out of his or her Ford Fiesta and strap them into an F-16. In practice, Modula-2 was too much like driving a milk float or a pedal car, and it rapidly became drudge-work. I truly cannot see how you would engage a child with even the most skilfully-constructed exercises in this family of languages.

But... Learning to program rigorously and carefully in procedural Pascal stood me in good stead when I started writing commercial code in Visual Basic. Many, many mistakes were avoided. And the bane of my life is unpicking bad C++ written by the Quants, who are taught to code in it without being taught how to program.

I still have no idea how to teach anyone O-O programming. I hear good things about SmallTalk from developers I respect but, for us, it was endless handwaving and talking about tasks in abstract terms, which never seemed to get anywhere concrete with recognisable components performing discrete tasks. I'm self-taught, and it says something that I came to understand inheritance through discovering the limitations of VB! Even with the best of tools, it takes a talented teacher to explain the concepts of O-O and I suspect that the majority of taught courses teach nothing more than the useful-in-real-life art of using buzzwords and skilful handwaving to impress an ignorant audience while concealing one's own conceptual confusion.

Which leaves me contributing nothing to your discussion. Functional is the way to go, especially when teaching first-timers, because you can see it working; but I lack a formal training in it and would do well to leave such advice to experts. I'm told that Python is the best contemporary language for encouraging legible code and, having seen some, I believe this to be true. But that is hardly a useful (or even reliable) recommendation, either. Logo is new to me: I haven't seen it in use.

For someone who is arguably among the most commercially-successful coders on your friendslist, I have to admit that the best I can do turns out to be a miserable excuse for a worthwhile answer.

[kaet.livejournal.com]

My alterior interest for this is actually for teachers/parents.

Educational software is almost all entirely crap because it's not written by teachers or parents, and cannot be written safely by teachers in a modern networked environment. By putting machines which children can program, there's a good chance that parents and/or teachers will have sufficient brain and time, between bringing children up, to implement something.

The educational and "play" (rather than game) software available for the Beeb really hasn't been surpassed, unfortunately, :(. I used to say this expecting to be controversial, but the vast majority of people I've met in the field seem to agree, :(.

[kaet.livejournal.com]

I'd initially go for the TinyTuxBox, because it seems neater, because of its internal drive. The Linutop, with slightly its weird pen drive sticking out is fine for an industrial setting (though in the photo they had to build a perspex enclosure to keep it dust-free), but looks weird at home. I think having something that looks like "something you might buy" might help, even if it's not actually something that you're going to sell!

On the other hand, that's a minor point technically. I wonder if you can have an internal USB port on the Linutop?

I think pen drives are ideal as a modern storage mechanism. Kids often like dinky stuff like that.

[covertmusic.livejournal.com]

It was something I saw demoed at Scifoo; it was really impressive.

I'm not really qualified to hurl rocks in the OO/non-OO debate, but the language I'm most interested in learning for the fun of it, as opposed to work (where Java and JavaScript are top of the list) is Max/MSP or the (closely related) Pd - both of which are pretty extremely graphical. They're as special-purpose as it gets, though.

[covertmusic.livejournal.com]

Oh, another couple of thoughts, mostly for possible inspiration: Nodebox and Processing.

I'm a big fan, and have made real use, of both.

[pm215]

Making it easy to do amusing stupid things

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

[pm215]

I still have no idea how to teach anyone O-O programming.

I suspect that OO is one of those things where the real reason for doing it is that it makes it easier to write (some kinds of) large programs. So it's very hard to come up with useful teaching examples because if they're sufficiently large that OO is obviously better then the example is hard for the student to grasp and would take forever for the teacher to explain. On the other hand if the example is small enough to be a sensible example then the student not unreasonably thinks 'what is the point in all this OO complication?', and possibly 'this bizarre contrived example bears no relationship to the Real World'.

The design patterns stuff I think suffers from this to an even greater degree.

Debug.Assert

[hairyears.livejournal.com]

I have to agree with that. Interpreted code is a very effective way to understand a computer program. Note, however, that commercial variants of Basic have both an interpreted and a compiled mode; the majority of VB developers are unaware of this through ignorance, the majority of C++ developers through disdain.

But all of us use 'stepping through the code' debuggers - a feature of modern IDE's which never ceases to astonish me; halting a compiled program, picking up the pieces and running it line-by-line on-screen as if it was an interpreted language.

[hairyears.livejournal.com]

No, programmes don't have to be large before they benefit from O-O design: think of running next year's income forecast on a mixed portfolio of 20 bonds and shares.

[pm215]

Perhaps. I have to admit that I don't really do any OO programming; mostly it's systems programming in C, which is (obviously) generally non-OO, with a little bit of roll-your-own ad-hoc method dispatch where it's obviously sensible.

Re: Debug.Assert

[bens_dad]

I remember single-stepping C code in an IDE in 1993. Except that it was an SGI with a mips R4000 with multiple pipelines (IIRC) and a reordering compiler, so it became a case of watching *two* execution pointers jumping backwards and forwards :-)

[gareth-rees.livejournal.com]

I'm not sure it's worth worrying as much as this. If children are interested in programming, they will grab whatever opportunities they can get with both hands. (I wrote my first programs on an HP-15C, and I wrote my next ones on paper after reading Illustrating Basic by Donald Alcock, since I had no computer to try them out on.) If they're not interested, then no environment will make them, and hunting for a setup that's "just right" will only lead to disappointment.

I also think your worry about Basic is misplaced. Someone who has aptitude for programming will have no trouble moving on to other languages; someone who gets hung up on the very minor differences between one programming language and another is going to have a lot of other difficulties.

By the way, I think Blitz Basic has a lot going for it. It's easy to draw stuff on the screen and it has 3d graphics built in. I would have loved it as a kid.