Teaching programming [was: How to cheat in exams using mobile phones and calculators]

[Barb Knox]

[snip]

[T]he biggest problem is because they're good hackers, it's hard to
convince them of the benefit of switching to a more disciplined style.

And they tend towards arrogance, with the attitude that they are good
enough to hack *anything*. This comes from only ever having worked on
self-selected hack-able problems -- they haven't yet met "the program
with their name on it", meaning one that is just too complex to hack
without doing a decent design first.

I had the fortunate early experience (although it didn't feel fortunate
at the time) of having to do a lot of maintenance work on large messy
programs, which convinced me in my bones of the need for clean design.

Personally, I think this is the best way of doing it. If you understand
what
is really happening at the machine level, then when you are introduced to
objects at university you just shrug and say "oh that's a more convenient
higher level abstraction for what I'm already doing". The biggest problem I
saw with undergraduates was they couldn't understand the abstraction because
they hadn't experienced the problems of programming without objects, and
they
didn't know what was being abstracted.
I realise that advocates of the 'objects first' approach that seems popular
lately will disagree with me here!

My own experience is that constantly wanting to think of abstractions in
terms of "what really goes on underneath" serves as a barrier to good
use of them. So, yes, I am an objects first person - when I program in
an OO language I want to think of it in terms of abstract objects passing
messages between each other, and not as just one big block of code and one
big block of memory where the OO constructs are just a way of organising it.

Yes, but.... The sad fact is that most students seem to be generally
hopeless at *anything* abstract. Of those students, the ones who have
some sort of concrete model of "what really goes on underneath" have a
big advantage over the ones who don't.

A good example of the way in which wanting to see it in terms of what goes
on at machine level is the difficulty I've often experienced in teaching
self-taught hackers the use of recursion. Somehow they just can't get
away from thinking of it as "this calls that then that calls this, then,
oh woops, it's all too difficult, I'll cobble together something with
a while loop and global variables".

Indeed. IMO, recursion is the /pons asinorum/ of introductory
programming, where the abstraction-challenged students visibly hit the
wall. But note that it can be taught in a less abstract manner, e.g. by
starting with recursive function patterns that are actually iterative in
structure (i.e., tail-recursion).
--
---------------------------
| BBB b \ Barbara at LivingHistory stop co stop uk
| B B aa rrr b |
| BBB a a r bbb | Quidquid latine dictum sit,
| B B a a r b b | altum viditur.
| BBB aa a r bbb |
-----------------------------

[Brian Harvey]

But note that [recursion] can be taught in a less abstract manner, e.g. by
starting with recursive function patterns that are actually iterative in
structure (i.e., tail-recursion).

But this runs the risk of encouraging students to develop the "go back" model
of what recursion means. I prefer to start with an embedded recursion, to
torpedo that idea at the outset. The way to make recursion less abstract is
to start with examples that *do something visible* at each step -- print a
word, draw a line, etc. A fractal tree is the canonical example, but my own
favorite is

to downup :word
print :word
if emptyp :word [stop]
downup butfirst :word
print :word
end

? downup "recursion
recursion
recursio
recursi
recurs
recur
recu
rec
re
r
re
rec
recu
recur
recurs
recursi
recursio
recursion
?