In article <
MPG.ff322ab6...@nntp.hpl.hp.com>,
Larry Rosler <
l...@hpl.hp.com> wrote:
>As one of the first who tried to teach C many years ago, I can vouch that
>it is a poor choice for beginners, for one spcific reason that is seldom
>discussed: the difficulty of doing simple text input with data
>conversion.
>
>Once one gets past single-character input (getchar or getc) or perhaps
>line-at-a-time-and-parse-it-yourself input (gets or fgets, atoi, atof,
>...), one encounters the horrible scanf function, which demands an
>understanding of pointers and internal representations. Fuggedaboudit!
I had to teach an introductory programming course in C to people with
no programming experience, and the first thing I realized was the
problem you describe.
So I pondered my two choices: (1) Avoid sprintf, perhaps by giving them a
library of special-purpose input routines, or (2) Cover pointers very
early on.
I decided that (1) was essentially a waste of time, because the skills
and techniques they learned for dealing with my special-purpose input
functions would be useless.
But more important, I asked myself where the problem was really coming
from. I want to teach scanf, but to do that, I have to teach
pointers. Why does scanf need pointers?
`scanf' needs pointers because without them it cannot modify variables
in the calling subroutine. Why not?
`scanf' cannot modify variables in the calling subroutine without
pointers because the variables are lexically scoped so that they can
be hidden from other subroutines.
That decided me. Data hiding and encapsulation issues must be at the
heart of any programming course. By avoiding pointers, I would be
avoiding these elementary issues.
It turned out that pointers were very important and very essential.
They presented themselves in the earliest parts of the material not
out of perversity, but because they were central to the topic.
So I went with choice 2, and I discussed functions and private
variables in the second lecture. Then, by the fourth lecture, with
the idea of private variables already established, I discussed scanf
and pointers. I did not discuss arrays or pointer arithmetic until
much later.
This all worked very well. It is a very little pill to swallow.
Everyone understood. Later on, when we discussed arrays, the pointer
arithmetic part was a smaller pill because everyone was already
familiar with pointers.
It was a huge success, and it left me convinced that the problems with
teaching people pointers are on the delivering end, not the receiving
end. I think that people teach pointers the wrong way, and usually
the instructors do not understand pointers themselves.
Summary:
Pointers are an essential part of the solution to the data hiding
problem, which is an essential issue. Therefore, they cannot be
avoided, and in fact should be addressed as soon as possible. The
idea of a pointer should be separated from issues of pointer
arithmetic, which is not necessary until later.
Note crossposting.