[Tutor] Teaching computer programming

[Christian Tismer]

John Kleinjans wrote:
> 
> We must remember that teaching _programming_ differs from teaching a
> programming _language_. So if we want to develop some materials for
> "teaching programming with Python", we need to focus on teaching
> *programming* first.

First, I usually try whetting their appetite. I show something
to them that looks quite "spectacular" which they think they
are far away to reach it. Then I show them the ridiculously
short Python script which did it. I let them repeat it step
by step, and they feel the power. Then it is time to try
to explain what's going on. This might fill the whole course.

I had most success by showing them Office automation. But
well, they were no absolute beginners, no kids.
What you would need would be some challenging graphics
application which makes them eager to learn scripting.

> A personal note:
> 
> I like to teach programming for (at least) two reasons. One is because
> teaching
> people how computers work, and how to make computers do what they
> want them to do, gives them power.  The other reason is that it teaches
> people how to think in a logical, connected, sequential, directed way.
> That gives them even more power; power over their own minds, power to
> control their thinking and the sequences of ideas in their own heads.

You seem to be in the happy situation to teach kids.
They are in highschool (and cannot run off if it's boring),
and they are in fact able to learn a different kind of thinking
in that age. Much less with my grown-ups, there is not much
chance to install something completely different, since
the brains are very much settled already.
And I have to fight the "what is it good for" question
all the time, since I'm wasting paid working time.

> I think that teaching computer programming is a very powerful tool for
> teaching people how to think clearly. The program runs, or it doesn't. It
> does what you want, or not. The cause is (usually) in plain sight, in the
> source code; the error is in one's understanding or precision.

Hmm, this is true, for sufficiently trivial pro(gram|blem)s :-)

In "real world" (which is quite often some Windows platform),
this is quite different since your program isn't alone.
My most beloved problem is if I get something running
in the debugger, but it crashes when run alone. This
sharpenes thinking even more, since you are trying to 
figure out what could be wrong, who is causing this,
is there a bug in the documentation or in some dll
which you have to use, and so on. This is no longer
deterministic, but defensive programming.

<snipping until those "boxes">

> Maybe say "a variable is a place to put a piece of data that can change
> (that's why we
> call it a "VARIable") and that we want to use later. Maybe call it 'box1'
> (and 'box2',
> etc.) to allow us to use that metaphor, and help the learners learn to
> think clearly and
> correctly about these things.
> 
> Now we have input, output, and variables. How much can we do with that much?
> Can we now give learners a few programming assignments? It's tough, with no
> 'if'
> or 'while', but such is life.
> 
> --Write a program to take in two numbers and return the
> sum/difference/product/quotient. Or maybe all of the above.
> 
> box1 = input("First number: ")  # User types a number; it goes into box1
> box2 = input("Second number: ") # User types another; it goes into box2
> box3 = box1 + box2                      # Add what's in box1 and box2; put it into box3
> print box3                              # Show what's in box3
> 
> So when 'box' is on the _left_ of the equals sign, we *put something into
> it*. And
> when it's on the _right_ of the equals sign, we *see what's in it*. (I'd
> say that we
> 'get' what's in the box on the right, except that what's there _stays_
> there--it's like,
> when I tell you something that doesn't make me forget it!).

Well, let me dig in here. It is correct to give this simple
view to beginners in the first place. But yu need to be aware
that this is not very true in a language like Python. Some
day later, you must try to get the full truth to them.

Variables in Python have almost nothing in common with variables
in QBasic or any other compiled language.

Boxes are ok so far. Boxes take the values.
But variables are better seen as lables, sticked to the
boxes. They just hold a reference, not the value.
This is hard to recognise with simle number or string
variables, but as soon as you are dealing with structures
like lists an tuples, the difference will be very visible.

I can only recommend to read the documentation about
Python's object model very carefully and learn about that
whatever you can, since you will run into the following
situation more or less early:

Your kids find out that they can do
a = range(3)
b = range(3)
or also
a = b

Now, they modify the "box" a by
a.append("howdy")
and look at b, which has changed as well.

They will ask you what happened, and you must be prepared
to give a good answer which they understand. The list is an 
object, with a and b being labels sticked at it.
This is also true for many of the simple types like string
and numbers. They are often shared objects, although in this
case it makes no difference since they cannot be changed.
If they get that right, they will avoid a lot of mystic
errors in their future programs.

> Aha! We should explain 'commands' and 'functions'. But maybe not just yet!
> At least, we do need to point out that 'input' has parentheses after it,
> and 'print' doesn't.

Maybe you could use this opportunity to introduce functions
as first class objects in he first place? You don't need to
use difficult wording, but give them just an "input" or
some other function like "max" and let them play with it.
Tell them there is a thing like "max" which can be assigned
to any variable as well. It just happens to be callable.
They can invoke it by putting arguments in parentheses
behind it. But they also can inspect it, look at its __doc__,
take a dir() from it, and so on.
This is the basic interactive playing with mud which so many
other languages are lacking. This can become real fun when
they begin to find out things alone.

> It occurs to me that teaching programming must be 
> (I've come to hate the word) proactive. That is, you 
> can't just wait for learners to ask questions, because they
> don't know enough to ask the right questions in the 
> right sequence. You need to initiate and introduce 
> sequences of ideas. I don't expect my students to
> invent pointers, much less linked lists. Shoot, most 
> of them are hazy about differences between integers and 
> floats ("something we saw in math").

Give them a small problem, solve it with them, and let them
explain what they saw. Of course they don't need to invent
pointers. Throw a list at them, and they will ask you
good questions. Python is such a smart tool which gives
you data structures at your finger tips, without having
to teach all the mess about pointers, memory, element size
and whatsoever. 
When I remember the 2 semester programming course which I 
attended in 1979 (in Algol 68 which already was high level
and very modern stuff), I have to say this would have been 
even more effective using Python.

> I think that there's a lot you can teach people who 
> only know 'print' and 'input()'.
> 'if' is a good next candidate. Right after that, 'while' 
> is useful, so the user doesn't
> have to re-start the program for each run.

I'm in doubt wether it is good to start with "input"
at all. It does an evaluation of the user's input
already, and how do you want to explain that?
I would use raw_input, or better nothing at all.
Let them just assign values to variables.
Then, I would try to get them writing their own
little function as early as possible. Let them feel
that they can build their own tiny callables which
are similar to the builtin functions and imported stuff.

I would even do this before coming to control structures,
since writing useful functions is one of the biggest
hurdles for most beginners which I've seen. They end up
with large "main" programs and lots of global variables.
Writing tiny functions from the beginning is something
which you can achieve easily with Python.

Where are they in math, BTW? Writing a couple of functions
which solve their math homework can give a lot of
motivation :-)

ciao - chris

-- 
Christian Tismer             :^)   <mailto:tismer@appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101   :    *Starship* http://starship.python.net
10553 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     -- Python changes both our learning and our teaching --