[Tutor] Teaching computer programming

[John Kleinjans]

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. 

-----

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. 

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. 

This is not to say that logic is the only, or even the best, way to
think--but 
it's a powerful and necessary tool for one's mental toolbox, and one that 
too few people have or can use. Intuition is good, too... and an aesthetic 
sense... just use the right tool for the job at hand. 

I think that it's good for one's personal development to learn to program, 
somewhat as participation in athletics is (supposed to be) good, whether 
you ever program/play for money or not. Learn how to use your mind _and_
body. Left _and_ right brain. 

Yada yada yada ...

-----

Back on subject. So, once they get the compiler/interpreter environment 
operating, and learn a process for typing instructions and getting the
computer
to execute said instructions (or choke on them and cough out error messages);
what is it that people need to learn, in what sequence, to learn 
_How_to_Program_in_Python_? 

In QBasic, I start with ...

PRINT "Hello world"

... and then go to ...

INPUT "What's your name"; name$
PRINT "Hello "; name$

... and already we're talking about variables, variable names (name$), data
types, 
input and output--there's a bundle of concepts that (it seems) have to be
handled 
as a group. In Python, we can (I think) ignore the whole 'variable types
and names'
mess, which simplifies this step to teaching input, output, and variables. 

So someone new to programming will want to know what a variable is, and why 
we need variables (we're teaching _programming_, remember). And we want to 
tell them something that is _true_, yet not necessarily exact; something
they can
understand, use, and build on later without having to un-learn . Most
newbies don't 
want or need to hear about allocating a block of RAM and creating a symbol
table 
with addresses... save that for later, when they need to know. 

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

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. 

-----

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

Of course, there also comes a time to shut up and allow the learner time to
digest 
stuff. It helps to give them projects of the right size. 

-----

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. 

Later -- John