Do NOT teach programming in abstract terms. Was: Can Novices Jump Directly in C? (Books)

[house ron]

scs at adam.mit.edu (Steve Summit) writes:

>However, it is not (I hope) necessary to think in lowest-level,
>hardware terms to learn and use C effectively.  Were this in fact
>necessary, C would be quite a failure as an HLL.  It is true that
>most experts can and do think in hardware terms when programming
>in C, whether they have to or not, and this way of thinking is
>unfortunately often reflected in their teaching and writing.

I don't think you mean this.  "Lowest-level" hardware terms would
include descriptions of the voltage levels in the adders etc.

>My biggest complaint with most introductory C textbooks I've seen
>is that they unabashedly explain everything in hardware terms,
>referring to "machine addresses" and "word sizes."  Frequently,

On the contrary.  Too many textbooks and instructors in the more
esoteric universities deliberately teach programming in an etherial
style which bears no relation to the actual world.  Thank heavens
C books avoid this.  In fact, and this is my main point, IT IS
VERY MUCH HARDER TO START WITH THE ABSTRACT AND MOVE TO THE CONCRETE
THAN TO START WITH THE CONCRETE AND MOVE TO THE ABSTRACT.  That is,
teach by examples!  THEN show the principles behind them.  See later.

>they provide exercises which suggest that students write
>deliberately nonportable, machine-dependent programs, either to
>show why they don't work, or to discover parameters (word size,
>endianness, etc.) of the student's machine.  This has got to be
>bewildering to the beginner.

Yes, this is bad.  "Hardware" and "Non-portable" are NOT synonyms!

>Getting back to whether or not you need to think about the
>hardware in order to understand C, here's a frequent question
>which is often answered in low-level, hardware terms:

>     Q:	I had the declaration char a[5] in one source file, and
>	in another I declared extern char *a.  Why didn't it work?

>Curious people are often dissatisfied with a blanket answer like

>     A:	The declaration extern char *a simply does not match the
>	actual definition.  The type "pointer-to-type-T" is not
>	the same as "array-of-type-T."  Use extern char a[].

>They want to know WHY.  We have to explain that, given

[explanation mentioning pointers deleted.]

>As usual, a picture is worth a thousand words (they're just hard
>to draw well in ASCII):

>	   +---+---+---+---+---+
>	a: | h | e | l | l | o |
>	   +---+---+---+---+---+

>	   +-----+     +---+---+---+---+---+
>	p: |  *======> | w | o | r | l | d |
>	   +-----+     +---+---+---+---+---+

>We can see right away that both a[3] and p[3] are 'l', but that
>you get there differently.

>I don't claim to have invented this label, box, and pointer
>notation; it's used often.  (As I recall, there's a nice pic
>picture much like this in chapter 5 of K&R2.)

>Now, a lot of you are probably saying "wait a minute, he said he
>was going to explain it without resorting to hardware terms, and
>he turned right around and explained it in hardware terms."
>Though I was careful to use words like "location" and "place"
>instead of "address" and "memory," I have to admit that the
>discussion is still pretty low level.  Notice, however, that I
>didn't muddy the water by saying "suppose location `a' is address
>0x1234," and I avoided saying exactly how big that box that holds
>a pointer is.  I think anyone who has ever used a pocket
>calculator has some notion of a "register," namely a little box
>that can hold values; and no matter what computer language you're
>learning, you're bound to think about "values" being stored in
>"variables" that have "names."

I just love these nice simple pictures!  I use them all the time
while teaching programming.  BUT do you know that the majority of
students DO NOT KNOW WHAT THE ARROWS MEAN??  It is obvious to them,
whether you teach 'hardware' or not, that computers cannot contain
arrows!  Unless you explain clearly that the arrow is a NUMBER,
namely an address (just like a street address - that's not machiney!),
and show EXAMPLES of these addresses, over and over for a few weeks,
the average student is totally lost by these arrows in these nice
clean high level pictures!  It's a fact.  I've taught enough beginners
to see this repeated ad nauseum until I finally caught on that what
looked clean and simple to me looked unbelievable to the students.
They just couldn't relate it to anything they knew about that box with
a screen sitting on the desk.

>The point is that yes, you have to think about locations, values,
>arrays, pointers, and the like; but no, you don't have to talk
>about "the hardware," that ints are 16 bits, that pointers are
>really addresses consisting of a segment and an offset, that when
>you add an int to an int * the compiler actually scales it by
>sizeof(int), or any of those other "explanations" which somehow
>only manage to make things more complicated and harder to
>explain.

Partly true - segments etc, you are right.  But it is a big disservice 
to our students to deny them the underlying concepts which make
sense of the abstract pictures.  See my main point above.  The people
who rave longest about teaching things abstractly often have the
best knowledge of the underlying picture, but they don't realise
how deeply their own capabilities are rooted in that knowledge.

I have taught a lot of Pascal, and I have come to the conclusion
that C is a better beginner's language, precisely because it is
harder to obscure what's really going on.  Pascal students make
great progress rapidly, but a long way down the track, you suddenly
realise that something is wrong.  (Perhaps when you get to recursion,
or linked data structures).  I have been forced to the view that
the average Pascal student learns to program by PATTERN MATCHING.
That is, given a problem, write a solution which resembles a solution
to a similar problem seen before, without any understanding of what
is actually going on.  Then tinker with it until it works.  Retain
changes which make the output more correct, undo ones which make it
worse.  This usually works, unless the basic paradigm of the solution
is wrong, and then the student fails the assignment.

Remember, all mainstream computers are fundamentally the same.  Just
as bus and taxi drivers have to know what happens when they put their
foot on the accelerator, so does a professional programmer have to
understand the CONCRETE behaviour of the language constructs.  All
this does NOT mean that programs should be badly structured, or non-
portable.

--
Regards,

Ron House.   (s64421 at zeus.usq.edu.au)
(By post: Info Tech, U.C.S.Q. Toowoomba. Australia. 4350)