Hi all,

In another thread I got into a discussion with @Andrew_Stacey and @Ignatz about teaching programming to young children using Codea (and hence Lua). (In my case, I started one daughter at age 7 and another at age 10. Some of their similarly-aged friends are now interested too.) @Andrew_Stacey suggested I start a new thread for discussing approaches to that.

At age 7, part of the challenge is that even basic math skills (say, the notion of “multiplication”) aren’t quite solid yet. So I try to find a path that adds skills very incrementally while trying to keep a sense of wonder all along the way. So far, most of what I’ve done is *one on one*; i.e., I teach only one child at a time.

I started programming quite young myself around 1980: Back then, my aspiration was to write something like Space Invaders or Pac-Man, which was actually a nearly realistic goal for a 10-year old with a home computer of the time. Nowadays, the aspiration is in terms of something like Minecraft, which is far less realistic: So I think it’s harder for a child today to stay motivated than it was 30 years ago.

Anyway, on to some practical notes… suggestions for improvement welcome.

I start by explaining the notion of *coordinates* on paper. I.e., we spent a few minutes discussing what would be needed to tell a computer where on the screen something should appear. At age seven that question is too abstract, so I provide quite a bit of lead: “How about we tell it how far from the left edge and how far from the bottom edge we want to draw a circle?” Once she agrees that that would be a good way to describe a place on the screen, I explain that “distance from the left edge” is called the “X coordinate” and “distance from the bottom edge” is called the “Y coordinate” and usually we write the two in order with a comma between them, like this: 100, 200. Once she gets that, I suggest a little game: I give her a paper with a grid pattern and a list with pairs coordinate pairs and ask her to draw straight lines between the pairs of coordinate pairs. The list is carefully chosen to produce a smiley face.

Then I bring up a new Codea project on the iPad and explain that the stuff written in the `draw()`

…`end`

are instructions to draw on the screen. I let her play with the `background`

argument (i.e., the color picker) that’s in there and let her run the program to see the effect. It’s remarkable how entertaining that can be at that age

Next, I explain the `line`

call: I find it makes perfect sense after the discussion and paper game about coordinates. I type some arbitrary `line(...)`

in the program and show her the effect. Then I ask her if she’d like to write some herself (which she does; if she wouldn’t, I would probably suggest taking a break for an extended while). Translating the paper tracing game into `line`

calls is natural at point.

I also show `ellipse`

and `rect`

calls around this time.

This much can take me quite a few days, BTW. I don’t spend hours at a time on this. Just a half hour here and a half hour there. Also, we frequently ask about her programming goals, explain that I cannot realistically walk her through a Minecraft implementation, suggest something else (tic-tac-toe, at first), and remind her that even achieving that will require her to practice much.

Next, I show `print`

and explain that for now she should only use it in `setup() ... end`

. For fun, I show her what happens when you put it in `draw()...end`

and explain that `draw()`

happen 60 times a second but the iPad is so fast that it can do a lot of things between to such drawings (“wow!”). I introduce the idea of variables from `print`

, just showing variations like the following. First:

```
print(7)
```

Next:

```
print(3+4)
```

Then:

```
x = 7
print(x)
```

And now:

```
x = 4
x = x+3
print(x)
```

Or even:

```
x = 4
print(x+3)
```

Once she gets that, I combine it with the coordinates idea:

```
function draw()
circle(x, 100, 50, 50)
x = x+1
end
```

Tadaa! (After a while it sinks in what is happening.)

Next I explain numeric `for`

-loops and spend quite a bit of time trying to get her to come up with loops on her own to do various things. E.g., find the sum of the first one thousand integers, draw 10 circles on a line, draw 100 circles in a square arrangement, draw a pyramid of circles, etc. This turns out to be remarkably hard (which is why I spend so much time on it).

Then `if-then-else`

, comparisons, `and`

, `or`

, and `not`

. Again, not easy, and I try to think of a lot of little examples (one I remember: I explain `fill`

and `color`

— which they readily get — and ask to change the square arrangement of circles to fill one circle with a different color). `break`

also gets explained around this time.

Next are tables, which I also first start on paper (a table with two columns, having in the left column the names of your friends, and on the right their ages). When I move to code, I only show three table primitives:

```
ages = {} -- start a table
ages["Natasha"] = 9 -- update a row in the table
print(ages["Natasha"]) -- look for something in the table
```

And finally, the `touched`

function (with my first daughter I started with currentTouch instead, but that turned out not to be helpful). Note that for `function touch(t)`

she doesn’t learn about `t.x`

at first; only `t["x"]`

. Since then I have shown her the shorthand notation, but I waited until I felt she was solid on table use. This is also where I tell her how to organize her overall program: `setup`

is only to set the initial values of variables and tables, `draw`

is only to draw (not updating variables and tables that are used outside of `draw`

), and `touched`

is where variables and tables are updated.

This is more or less where we’re at with my youngest (who has had a birthday since the start of this). She does know about `sprite`

, and likes to make drawings in *Art Studio* (another iPad app) which she then exports via the pasteboard to her Documents. She also understands functions (caveat: we haven’t discussed `return`

yet), but she hasn’t acquired the skill to decompose code into reusable functions.

My oldest (age 11 now) understands functions a bit better, understands some of the `tween`

functions (and hence callbacks), and has started simple `physics`

. We’ve got a ball bouncing.