Leonardo,
I agree with the "use examples from real life" idea. 3 ideas come to
mind: eggs, books, and using yourself as a robot. And, also, dealing
with pointers. Here you go:
1) Eggs: Find the broken egg in a carton of eggs.
(Forgive my lack of knowledge about purchasing eggs in Colombia, but
this would work here...) In the U.S., eggs commonly come in cardboard
packages, 6 eggs across and 2 eggs down. The package has a little
pocket for each egg:
O O O O O O
O O O O O O
I always check the cartons for broken eggs. The process of checking
each egg requires walking through a 2-dimensional array of eggs, left to
right and top to bottom. If the broken egg is in row 2, column 3, like
this:
O O O O O O
O O X O O O
...then I'll have to search through this 2D array to find it: inspect
each element in row 1, and the first 3 elements in row 2.
2) Finding a specific book in a bookshelf.
If you have a shelf of books organized by author, and within author by
title, finding one particular book requires walking through an in-line
representation of a 2-dimensional array:
book #: 1 2 3 4 5 6 1 2 3 1 2 3 4 5 6 7 1 2
author: A A A A A A B B B C C C C C C C D D
If you have multiple copies of the same book, you have a 3-dimensional
array (books A2 and C4, below):
_____ _____
book #: 1 2 2 2 3 4 5 6 1 2 3 1 2 3 4 4 4 5 6 7 1 2
author: A A A A A A A A B B B C C C C C C C C C D D
3) Have a robot (you) find a book
One technique I've used for teaching programming (in general) is for me
to be a "robot." It works like this: put a set of instructions on the
board (like "turn right," "bend over," "stand up", "walk," "grab book").
At one side of the room, put a book on a chair. Walk to the other side
of the room. Now tell the students to make YOU pick up the book -- but
they're only allowed to use the instructions on the board. Then you
stand still and do only what they say. If they say "walk," you walk...
and keep walking until you hit a wall. (They laugh.) Someone will
figure out to tell you to turn left (or whatever), and you do exactly
that and nothing more. (They get frustrated.) And so on. Eventually,
they'll get you across the room (stubbing your toes on the wall,
smashing your knees into the chair, and so on). I believe this gives
them a sense of what programming and debugging are like.
Given that: put a set of books on the floor, in a row. Then put a set
of instructions on the board that will get the students to make you
select a specific book (by title, by color, etc.), or the book in a
specific slot. If it works, they'll have to walk you through the array.
The instructions might be:
walk
turn left
turn right
bend over
stand up
grasp book
examine book
release book
go to next row
go to next column
go to previous row
go to previous column
go to start of array (and define "start" as, say, the top-left corner)
go to end of array (bottom-right corner)
...etc.
Once they get that, you can add to it: put books in several rows
(2-dimensional array), piles (3 dimensions), have multiple copies of the
same book in 1 pile (4 dimensions), etc.
4) Reference vs. value
So... in "real life" (in computer programming), variables are either
stored by "value" (where the content of the variable is in a specific
memory location) or by "reference"/"pointer" (where a memory location
merely contains the the LOCATION of the content, but not the content
itself).
You could use the techniques above to cover that, too:
- Eggs: have a bunch of spots on the floor, with big labels: "GOOD EGG
#1", "GOOD EGG #5," "BAD EGG #2", etc. Put good eggs and bad eggs at
those spots. (Perhaps in plastic containers...) Then, in your egg
carton, put a piece of paper with the eggs' labels. This shows that the
array doesn't contain the original items, just pointers to them.
- Books/robot: same idea. On the floor, have piles of index cards,
where each card tells you the real location of the book (perhaps on a
bookshelf on one side of the room). This will not only cover the
concept of "pointers," but will make the students walk you through TWO
arrays -- the "card catalog" (the array on the floor), and the bookshelf
itself.
What do you think?
If you come up with improvements, I'd love to know.
Ron
----- Original message -----
From: "Leonardo Parra Agudelo" <[email protected]>
To: "IXDA list" <[email protected]>
Date: Sat, 28 Feb 2009 14:17:17 -0500
Subject: [IxDA Discuss] Teaching to program: arrays.
Hi all,
I have been teaching how to program to non-engineers, mostly
designers, artists and a few musicians, and it all goes well until we
hit the arrays. At this point, it gets tricky. I have tried a few
different approaches, but since many of you here have gone through
the learning process, or teach programming, I was wondering which
methods had worked for you, and what do you think could be improved
when you compare your learning process, to some other strategies
you're familiar with.
I'm using processing.
You can take a look at some of the exercises here:
http://design.uniandes.edu.co/medios/cursos/dise3308-091-02
It's all in spanish, but click around.
: )
Leonardo.
Leonardo Parra Agudelo
Full Time Faculty
Design Department
Architecture and Design School
Universidad de Los Andes,
Bogotá, Colombia
[57-1]-3394949 xt 3268
________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... [email protected]
Unsubscribe ................ http://www.ixda.org/unsubscribe
List Guidelines ............ http://www.ixda.org/guidelines
List Help .................. http://www.ixda.org/help
________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... [email protected]
Unsubscribe ................ http://www.ixda.org/unsubscribe
List Guidelines ............ http://www.ixda.org/guidelines
List Help .................. http://www.ixda.org/help
