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

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

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.)

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

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

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