[Tutor] Teaching computer programming

[John Kleinjans]

At 03:13 PM 4/5/99 +0200, you wrote:
>John Kleinjans wrote:
>> 
>> We must remember that teaching _programming_ 

<snip>

>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.

You call it a "script". Is this the same as a "program"? Or is there
a functional/conceptual difference? I know Python is sometimes 
called a "scripting language"--maybe you can tell me what that is? 

>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.

Anybody know of a/some good one/s? 

>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. 

Yes, I do teach kids. I teach in a poor school district, and most of the
kids are two years (or more) below grade level. My biggest problem 
is to get them to _try_, to get the kids to make an effort, to attempt to 
actually think--because they got along until now, and maybe never 
saw much thinking before. They think that thinking is hard work, not 
fun! And that living on government aid is a career... and that fighting 
and being in a gang is cool...  

So I can have a big impact on someone's whole life, if they want it. I 
keep telling them "a teacher can only bring knowledge to your eyeballs 
and eardrums--YOU have to move it the last 3 inches" (about 8 cm). And 
if they can start doing _that_, then we can go somewhere. 

And if they make an effort, they will have some success--and if they have 
some success, they might make an effort again...

But back to teaching programming with Python.

>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.

So what is a baby good for?  ;-)

>> 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.

And we'll get there, too, one step at a time. Then we're getting 
to a place where we need to understand how programs 'think', and
how they share information with each other--how the system works. 

But for a person first learning programming, that is far away. 
First crawl, then walk, then run, and fly... then maybe "beam me up, 
Scotty". 

So we start with "trivial" programs--the first step looks small 
when you look back down at it, but it can seem very big to those 
who are looking *up* at it. 

><snipping until those "boxes">

<snipping some more...>

>> 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.

This is why I (John) put this here. I don't know objects--this is one 
reason why I feel that Python is a good next step for me. And I want to 
test ideas with you. 

When teaching procedural languages, we need to teach variables 
quite soon, because programs with no variables don't let us do 
interesting things. 

I have this feeling that objects are different ('feeling' because my ideas 
aren't clear, because I don't know, and I know that I don't know). So, 
what should you teach to a person learning programming for the very first 
time? Is there a more productive first look to show 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.

So maybe we tell learners that 'box1' and 'box2' (or 'x' and 'y' and 
'total') are _labels_ on the boxes. That is, when I type in "John", that 
has to go somewhere (into a "box"); and maybe we label the box 
'fname', say. Similar idea, but a different emphasis. Is this a more 
productive way to present it? Or am I still stuck in the old thinking? 

>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.

Because we gave to one thing more than one name? We have one 
box, but we put two (or more) labels on it? 

>> Aha! We should explain 'commands' and 'functions'. 
<snip>

>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.

There's some language here that I don't understand. "first class 
objects", "assigned", "callable", "invoke", "arguments", "inspect", 
"look at its __doc__", "take a dir()"  ... 
well, I know some of them--but students think that "callable" is 
someone with a telephone, and an "argument" is when you don't 
agree, "assigned" is where you sit, and so on. There's a lot of ideas 
inside each of those words. We have to help students build each 
idea, and then help put them together. 

Of course, it's better if they can experience it first. Then when you 
name it, they already know it--then it's easy. 

(The best teaching is like the best writing--the learners (readers) think 
it's real easy, and that the teacher (author) is doing nothing at all. When 
they go "Oh, that's obvious", then you know you set them up well.)  

If you name it first, before they see it, most kids get scared and 
can't think; or they define it (incorrectly) in terms of thingas they 
already know--and may have to un-learn that before they can 
understand. 

So maybe you have a small example program, then some "words" 
(commands or functions) to mess around with? 

<snip>

>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.

I agree--modular programming styles should be encouraged 
early. In-line code is a thought pattern that can be learned easily 
and un-learned with difficulty. 


>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 --
>