[Edu-sig] Oh, the TEACHERS!

[Lloyd Hugh Allen]

On 9/8/06, kirby urner <kirby.urner at gmail.com> wrote:
> (2) prompting oneself for input is a holdover from prehistoric dino
> terminal window days and should not be front and center.  Just like
> with 'copy' we put it up on a shelf, to discourage accessing this
> 'honey jar' of a previous generation (bad habits are hard to break)

I was thinking about that this morning. I used to teach programming
each summer at a math camp, and as a math teacher I have an
opportunity to directly teach a programming course every few years (we
have two math teachers with CS degrees who each do .5 to .8
programming, but every so often there is an overflow section which
would tend to go to me).

The curriculum that I inherited and modified in order to teach
programming through Python, I initially translated from a nominally
C++ curriculum that looked a lot more like a C curriculum. I edited it
to include more object-oriented frame of thought, and injected some
Tkinter (which did wonders for student interest). The C++ / C
curriculum that I modified was probably a revision of a Pascal
curriculum, and I don't know the origin of that Pascal curriculum.

The model that I tried to convey to the students was that

First, a computer program has OUTPUT. We would use print for an
80-minute day and Tkinter for something like a week to simply produce
output (which is less boring if you include things like for loops in
this time).

Second, a computer program has INPUT followed by OUTPUT. This was
where raw_input was nice, and students were to use raw_input followed
by typecasting for numerical values.

Third, a computer program has INPUT followed by COMPUTATION followed
by OUTPUT. Eventually they learned to embed a try: except: in a while
not loop in order to force the user to give an expected numerical
value as the response to a raw_input request.

This summary does an incredibly poor job of conveying the pieces of
object-oriented thought that were included (e.g., string and list
methods early on), but what I see happening with dropping raw_input is
that we will probably want to completely and totally revise the
curricula such as the one that I just described. I see a little more
give-the-kids-a-black-box-module-and-have-them-call-it, which is very
popular in java programming. And, of course, I'll want to completely
re-write my own syllabus on the next round. Lots more Tkinter, most
likely.

This (need for curricular revision / rewriting from the ground up) is
not a wretched thing, but it is a time-consuming one; and almost every
utility program that I have written only for myself to use is now
going to be broken. I remember a bit of pedagogical pain when in
earlier versions of Python, all of the tutorials said to call a Tk
mainloop(); then in IDLE the programs would kill IDLE itself when
exited. So I told my students to write the mainloop() invocation, but
to comment it out. Eventually I forgot about it. Then when I took the
same lesson to a later version of Python, IDLE became smarter and the
mainloop() invocation became (properly) necessary again. Every time
that old code becomes invalid, there is a risk that not only programs
won't run, but (especially if the instructor trusts fundamentals not
to shift) lessons are broken as well.

Again, I'm not saying that this is a bad thing, but it can be a
painful one (especially if a new version of the language is embraced
without checking through all of the sample code in each
already-written lesson). There is also a risk that folks will freeze
at an older version in order to avoid breaking old code. I'm sure that
the obvious has also been stated elsewhere.

-Lloyd, a TEACHER.

(I'd tend to want to change the subject: too, but that would make it
hard for me/gmail to track the thread)