Two insights on teaching computer programming
kirby.urner at computer.org
Sun Jan 15 16:49:16 EST 2006
>Wouldn't teaching a programming language be similar? Having 8th-grade
>students "eyeball working code" written in a complex notation without
>really understanding what it's doing sounds like a recipe for disaster.
I understand your concern, thanks for expressing it so clearly (even though
I'm a moron about a lot of things French).
What we do hands-on is play around with collection types in the shell:
list, dictionary and string types mainly. Then we write some simple
function definitions, saving our work in a module.
This pattern of data collections and function definitions is something the
semi-trained eye picks out in gis.py, especially with a teacher as tour
guide. import statements sit up top (lots of language have those), then we
see by now somewhat familiar data structures (cities in a dictionary), then
some function definitions.
And that's what a typical Python module looks like -- except there's also
this class definition, which we haven't really discussed yet (we still have
3 weeks to go).
In my experience of tackling French, Italian and Spanish over the years,
I've found it helpful to eyeball "already working" (i.e. grammatically
correct) examples. Typical language learning includes reading stuff that's
at a level above what you can write. Such readings exercises recognition
versus recall vocabularies -- two different animals. Many scholars develop
a recog familiarity with Latin, but how many speak it fluently?
When kids go to science museums, they see cutaway views of electrical
generators, maybe a full sized decommissioned apparatus, such as we have in
OMSI (formerly a city power station). We don't expect kids to design and
build generators, or to articulate all the parts. But that's different from
eyeballing a diagram, seeing how stream drives a rotating magnetic coil.
Likewise the internal combustion engine: here's what it looks like, roughly
how it works, but we don't expect you to take it apart and put it back
together until high school, if then.
Here's an example of code we actually worked with last Tuesday. I had kids
type it in from a handout, debug it (with help) and then start tweaking it.
Changing the story means probably changing the key words, which means
modifying a list as well. I think of this as tinkering with already-working
machinery. More up close and personal than just eyeballing it.
Note: I find kids really like this 'Madlibs' approach, which I've used in
other classes as well. For one thing, it frees them from the tyranny of
"just numbers" (speaking from a private industry point of view, that's a
very important realization: computers are for alpha stuff, not just numeric
One creative student started using whole phrases, such as 'noun ending in
er' instead of just 'noun' or 'animal'. Given how dictionaries work, that
wasn't a problem, worked great.
More information about the Math-thinking-l