[Edu-sig] Queens, NY - PYTHON Programming for Kids

[Kirby Urner]

Tom --

You ask about metaphors.

The idea is to introduce new concepts using experiences kids
already understand and have a feel for.

You could say "computer memory is like a wall of bricks, 
with each brick being one byte" (byte-sized bricks).  That 
sort of sets the stage for those tall rectangle drawings,
where memory looks sort of like a skyscraper.  

That's another analogy:  "computer memory is like a building
and different floors are for different kinds of work". Then 
you fill in some lower area of the rectangle (I'm imagining 
a chalk board) and say "in most computer designs, the bottom 
floors get taken over by the 'operating system', which 
knows the most about the guts of your computer, knows all 
about the plumbing and electrical systems, elevators -- 
everything that makes a modern office building go.  If a 
toilet gets stopped up on the 28th floor, call the 
Operating System"  (kids go for scatalogical metaphors 
sometimes -- I'm not above using them).

I think this kind of "stage setting" is important, even if
you don't spend more than a few minutes on it.  Then you 
can say something like "your Python programs depend on the
operating system already doing its job -- Python expects
to be inside a working building with all the standard 
maintenance jobs being taken care of, needs that kind of
service in order to be productive, as do most programs,
such as word processors or games".

I think it's important for kids to get it early:  the 
computer world is a vast, sprawling bureaucracy in a lot
of ways, with lots of "black boxes" -- which means that
you can be a programmer without knowing everything about
how a computer works.  

The point of teaching about the ground floor OS is to 
give students a sense of why they're going to get to write 
programs, and not have to become technological gurus 
overnight -- you explain enough about the inner workings 
to make it clear why they _don't_ have to worry about 
low-level stuff.  That's what operating system does -- 
people have already written huge, complicated programs 
that you boot up and take advantage of every day.  They 
should get a feel for the high level of symbiosis here:  
because software and hardware engineers I'll never meet 
spent years learning to code at a low level, I get to 
write Python in a working office building.  And because
of the work that went into Python, I'll be writing 
little programs only 10 minutes from now.

A lot of metaphors are built right into the language, 
into any computer language.  For example, why do we call 
[1,4,5,3,'A'] a "list"?  What do we think about when we 
think of "lists" in the ordinary sense?  

Have kids brainstorm, throw out when "lists" come up in 
their lives.  "Shopping list" is an obvious answer.  
"To do list" is another.  Then you say, "suppose I change 
my mind:  I don't want grapefruit, I want peaches" -- 
you cross off something on your shopping list and write 
something else.  In Python:

>>> shoppinglist = ['eggs', 'grapefruit', 'pop tarts', 'cheerios']
>>> shoppinglist
['eggs', 'grapefruit', 'pop tarts', 'cheerios']
>>> shippinglist[1] = "peaches"
>>> shoppinglist
['eggs', 'peaches', 'pop tarts', 'cheerios']

Then of course "dictionaries" should be familiar to kids already.  
What do we do with dictionaries?:  look things up.  A dictionary 
is a place to store stuff in a way that's easy to retrieve.  
Gotta be careful here: Python dictionaries are not (don't need 
to be) 'alphabetized' in order to make retrieval easy (hash 
tables don't work that way).  Just say 

>>> myCDcollection['Pink Floyd']

and get back a list: 

['wish you were here', 'dark side of the moon', 'the wall'] 

or whatever.

Anyway, I think that's enough for now.  The main purpose
of metaphors is to link the unfamiliar to the familiar,
in order to keep the new concepts experiential, intuitive
-- something to be taken for granted in no time flat.

Kirby