Several times this year I’ve been dismayed to hear Annabelle say that she thinks she’s not very good at math. After asking her why she thinks this is I’ve learned that she worries that she has not memorized math facts as well as other kids in the class, and that she has to count on her fingers. While rote arithmetic is not something I’m interested in drilling the kids on, there’s something to be said for getting this out of the way so that the child can take the facts for granted. Doing this has been made less painful (it seems to me) by the availability of computer games that drill them.
Watching how kids interact with these math websites, though, it’s not been clear to me whether the appeal of the games is only due to the splashy action that is layered on top of the basic drilling, or if there might not be an intrinsic satisfaction to getting the answers right. It occurred to me that there might be an extra layer of satisfaction that would accrue from using a math facts drilling game that the child has written herself. Even if the game was a simple terminal text interaction, the fact that the program behaves as the child designed it to should make playing it that much more fun.
I proposed to both girls that together we develop a series of quiz-like games, and that the normal limits that we parents put on screen time would not apply for games that they wrote themselves. This seemed to be a fun idea, although we all realize that it may take a long time to develop such a game, and that by the time we’re done (or before then) interest may wane substantially.
My main goal is to get across at least some basic concepts of computer science. I’d like to do this over many very short sessions, so that the girls’ attention spans are not taxed and that the project remains fun. I’ll be developing the sessions in parallel for both Fiona (5th grade) and Annabelle (2nd grade), and there will be, obviously, some important differences in approach. The content presented by the quiz program will vary as well: Annabelle wants to learn her times tables, while Fiona has been working on State Capitals. But the core of the program we develop should be the same for all kids regardless of age. A secondary goal is to entice the kid into using a simple quiz program to drill themselves on elements of their schoolwork. Since the project to make a quiz game in Python from scratch will take some time, I set a modest immediate goal of having Annabelle understand what a computer program looks like, and how it can be modified to run in a way more to her liking.
What the parent/instructor needs to know (or be willing to learn): some very basic computer programming, using a language such as Perl or Python (or BASIC, even). For those parents who don’t know any programming, this might actually be a good opportunity to learn some: the concepts I’ll want to cover will be extremely fundamental, and I’m hoping that the material will be easily mastered by the instructor with just a small amount of preparation time. I’m very familiar with Perl, but will be taking the opportunity to learn Python, just to keep it interesting for myself. In addition, there is a phenomenal (and free!) eBook that discusses much of what I want to cover, using Python as its framework. The book, ‘Invent Your Own Computer Games with Python’ by Al Sweigart, has a target audience of kids as young as 10 to 12 years old. You can buy it as a paperback from Amazon, or download it for free from the author’s site http://inventwithpython.com/.
Preparations: Download and install Perl or Python. Python can be downloaded from http://www.python.org, and Perl from http://www.perl.org. Modern Macintoshes (those with the OS X operating system) have these pre-installed (though usually not with the latest version). It would be good to get version 3 of Python (Al Sweigart’s book assumes this), but I’d recommend against upgrading your Mac to a new version of Perl unless you use something called ‘perlbrew’.
There are many other resources on the web for learning Perl and Python, and I’ll compile the better of these as I come across them. But readers should feel free to let me know of any others in the comments.
Notes to the parent/instructor are indicated by [bracketed italics].
Setting the Stage: Today we started the discussion about how computers work and how they can be used. I showed Annabelle the Mac desktop and asked her what she knew about the program icons in the Dock. She knew that they were what you selected to do different things on the computer. I told her that they were sort of like a menu of choices that the computer was giving to you, but that if you really wanted to talk directly to the computer you had to open a program called ‘Terminal’ [this will differ by operating system, of course]. Even though we might be developing our program using other graphical applications, I want the kids to get the idea of a text-based interaction with the computer. I also want them to know that the graphics that they may associate with computer programs is an “extra” layer that sits on top of where the real work gets done. The graphics are like a disguise that a program wears. We can do a lot without having to build a whole graphics layer over our quiz game program.
Starting the Project: I decided to continue this theme of ‘looking behind the costume’ by playing a couple of rounds of ‘hangman’ with Annabelle, then opening the program file and modifying it according to her ideas. Sweigart’s hangman program uses several lists, including ones for the words that can be guessed, and one with the ASCII art depicting the process of a losing player being hanged from head to feet.
The progressively gruesome pictures look like this:
+---+ +---+ +---+ +---+ +---+ +---+ +---+ | | | | | | | | | | | | | | | O | O | O | O | O | O | | | | | /| | /|\ | /|\ | /|\ | | | | | | / | / \ | | | | | | | | ========= ========= ========= ========= ========= ========= =========
We decided to change the diagram a bit, to indicate flailing arms and an unhappy countenance. After some experimentation with the keyboard, Annabelle came up with this alternate depiction of the victim:
+---+ | | @ | ~Y~ | / \ | | =========
When we edited the program file and ran the game, Annabelle could see the consequences of her edits, immediately.
We next looked at the list of possible animal words that the computer is given to choose from. Annabelle noticed that there was one key omission: “kitten”. (Our new kitten Rue made sure to remind Annabelle of this by walking over the keyboard during most of our session.) We added “kitten” to the list.
However, since the program chooses an animal word at random, we did not initially see “kitten” appear. We discussed why this was and how we could figure out if “kitten” was indeed a possible choice from among the 20 or so other animal words. We decided that the best way to test our new entry was to bypass the game portion of the game, and simply have the program spit out it’s word choice. Our modified program looked like this [note that comments in Python are preceded by the ‘hash’ or ‘pound’ character ‘#’, and that the backslash ‘\’ allows you to split a line up so that it doesn’t get too long to read]:
# this line is boilerplate necessary to let us use the random number generator:
# this line is our list–please take note of the presence of ‘kitten’:
animals = 'ant baboon badger bat bear beaver camel cat clam cobra cougar coyote crow deer dog donkey\ duck eagle ferret fox frog goat goose hawk kitten lion lizard llama mole monkey moose mouse mule newt\ otter owl panda parrot pigeon python rabbit ram rat raven rhino salmon seal shark sheep skunk sloth\ snake spider stork swan tiger toad trout turkey turtle weasel whale wolf wombat zebra'.split()
# these lines define a function that picks a random word from a list:
def getRandomWord(wordList): wordIndex = random.randint(0, len(wordList) - 1) return wordList[wordIndex]
# these two lines use our function to get our word and print it:
word = getRandomWord(animals) print(word)
When run, this simple program prints the name of an animal (“weasel”, in this case). When run again, another animal pops up (“baboon”). Another go also yielded “baboon”, and a fourth run “mole”. Still no “kitten”.
We fixed things a bit so that the program, instead of printing one animal, would print fifty. Surely we’d get “kitten” by the fiftieth pick! To do this we replaced the last two lines of code with the following:
for i in range(50): word = getRandomWord(animals) print(word)
This, I explained, was a “for” loop, and one of the many kinds of loops a programmer can use. It’s inconvenient to have to say to the computer: “Give me an animal. Do it again. Do it again. And again” fifty times. It’s much more handy to simply say to the computer: “get me an animal 50 times”. And repetitive tasks are what computers like to do best!
Running our program gave us a list of 50 animals (many repeating) and sure enough, “kitten” was there (several times, in fact)! However, for our last task we decided that we should just have the computer pick an animal word until the kitten first appears. To do this, we replaced the last three lines of code with:
word = '' while word != 'kitten': word = getRandomWord(animals) print(word)
I explained that this was a “while” loop. Instead of saying: “give me an animal 50 times”, it says:
- start with a blank word
- while the word does not equal “kitten”:
- get a new word and print it.
Then stop. We ran it, and the final word was always “kitten”.
Annabelle’s Reactions: Asked for what she thought of the session, Annabelle repeated the “graphics as costume” metaphor that I introduced the subject with. She also offered that “computers can do a lot of things with lists”, which is exactly right. We didn’t talk much about random numbers, because we had touched on that topic for an earlier project, but I think there is a lot to explore there.
Next Steps: Going forward with the game idea, we’ll want to set up a method for picking random integers to add and/or multiply. We’ll have to have the computer assess right or wrong answers and keep score, maybe by imposing some graphically communicated penalty (though not as harsh as hangman’s capital punishment). It would also be nice to have a way for the player to choose difficulty levels.
Conclusions: Annabelle says she had fun and wants to do this again, and I agree. We spent about 40 minutes on the project, and were both pretty spent by the end of it. A lot of the success was due to choosing a quiet time when we were both fed and well-rested, and in the mood to talk about serious stuff. Trying to push this on her at a sub-optimal time would have been disastrous.
While I have no quantitative measure of outcome, I’d rate this first experiment a success. How successful it really was will only become apparent in subsequent sessions.