I've been thinking about your students and what possibly might be
going on -- aside from their not learning anything, which unfortunately
is possible.
I think that you are better off trying to teach programming in
conjunction with trying to teach test driven design, and unit tests.
A large problem I see with people learning to program is that they try
to do too much at once. As soon as they think of a a corner case,
they rush off to write code about it, while it is fresh in theie mind.
Quite often they end up with things that never quite work. And
when they show you things, you can see 2 or 3 obvious bugs in
the same code. Often they interact. So the poor student is
busy trying to fix part A of his code when it is part B, or
both part A and part B together that is the problem.
What this student needs, more than anything else, is an ability
to think in smaller chunks. Test driven design can really teach
you to decompose your problem into tinier pieces. And, when you
have a brilliant idea: -- Hey, this program should work when
I type 'Mr. Andy Judkis' -- you can just stick this idea into
a test, which will fail, but will make sure that you don't forget
it for later -- but not get in the way of writing the basic program
in the first place. and unittests teach you to write things in
small chunks.
unittests are nice for the teacher, as well, because you can
assign 'write code that passes all these unit tests' and then
write them in an orderly fashion, which will tend to influence
how the students write their code -- starting small and then
growing the problem -- much better than just telling them things.
Plus you can sit down and run the test suite and have a pretty
good idea how things are going before you start helping any student.
But this doesn't sit all that well with your 'interactice loop'
exercise. I wonder if it is the interactive loop part that is
the problem. After all, if you cannot get that part going, it will
be very hard to write the other bits. The last time I had students,
and these were rather young ones -- I taught them first how to
write programs that absolutely did something -- like print a
list of the first 10, then 15, then 200 factorials. This lead
to -- functions, and why we want them. Then it was time for
test driven design, and how to run tests with our framework.
We did a bunch of lessons like that before we got around to learning
how to input things, and even then it was much more common for
students to just have a running python interpreter, import their code,
and pass arguments to functions rather than have a proper main loop.
How to write functions, how to use them, how to use functions in
the standard library. How to find out what the heck there _is_
in the standard library. How to use each other's functions, and
a favourite, how to report a bug in your friend's function,
complete with a unit test that demonstrates the bug.
Despite all this experience, they found the actual getting and
parsing of text from a user, _really_ _really_ _hard_. Much
harder than anything else I had taught them before. And it was only
when I did a fast-forward to 'Exceptions', which I had started out
believing should be taught after classes, but now think should be
taught as soon as you start doing input, and 'never mind the
funny syntax that uses bits of the language we haven't learned
about yet' that some of them caught onto what was going on.
As your exercise stands, students who would not select yourself or
'Mrs. McGrath' would have a program that never terminated. I had
several students who were really, really, uncomfortable with the
idea, to the point of not being able to write code about it. They
were waiting to think of the way to do it which didn't have
this property. 'Real programs wouldn't work like that' they
quite rightly complained. It was only after I had taught them
about try: and except KeyboardInterrupt: that they were able
to get down to write things. Before their minds were wrapped
around what for them was the most interesting part of the
problem, whcih wasn't the exercise.
I guess the only way to find out is to ask your students. Good luck.
[I should revise this, but I must pack for Europython. If I don't
reply to replies to this, its not that I don't care, but that I expect
to be completely swamped with running the conference for the next
few days. In the words of Blaise Pascal -- sorry that this is so
long, I do not have time to make it shorter.]
Laura Creighton
