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

In article <Pine.LNX.4.61.0512131234110.27855@xxxxxxxxxxxxxxxxxxxx>,
Matthew Huntbach <mmh@xxxxxxxxxxxxxx> wrote:

>On Tue, 13 Dec 2005, Richard Smith wrote:
[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 |
-----------------------------

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

Relevant Pages
Loading