Can Novices Jump Directly in C? (Books)

[Erik Naggum]

In article <1991Feb9.042957.20160 at athena.mit.edu>, Steve Summit writes:
> In article <ENAG.91Feb8021615 at holmenkollen.ifi.uio.no>, Erik Naggum writes:
> >C is not well suited for first time programmers due to its intimacy
> >with the hardware.

> In article <11929 at helios.TAMU.EDU>, Sean Malloy writes:
> >I'm afraid that I have to agree with the above gentleman; C is not
> >generally good for first-time students unless they have a basic
> >knowledge of the hardware underneath.

...

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

There is a big difference between C being "intimate with the hardware"
in terms and definition and that its users have to have "a basic
knowledge of the hardware underneath".  I agree with Steve that
explaining things in specific hardware terms is not conducive to the
kind of understanding we seek, but knowledge of the von Neumann
architecture, of the stored-program computer model, of memory and
addresses, in short, of basic hardware functionality, is quite
necessary for a true appreciation of the language.  Now, this is miles
apart from "the hardware underneath", which is what most authors grab
and hold on to like life belts.  I'm not talking about _one_specific_
_hardware_, but of the _kind_of_hardware_ C is intimate with.

Only today, I spent some five hours explaining, in great detail and
with much code to support the narrative, why alignment requirements is
such a big problem, and why, if you do your own memory allocation, you
need to be very much aware of it, even worry about it.  This problem
can be dealt with in the abstract, without resorting to specific
hardware design or some specific alignment requirements.  Of course,
_examples_ come in handy, but you should get something out of them,
too, not just an enumeration of them; I'm a firm believer in teaching
by inductive methods.

> Furthermore, I believe that beginning (if not all) programmers are
> very strongly influenced by the code they see while learning, and
> that much of the deliberately awful code which is so often presented
> ... actually ends up being emulated.  If you never see good code,
> what else can you do but emulate the bad code you've seen, resigning
> yourself to the apparent fact that programming is an ugly job?

I'm happy to see that others express so well my heartfelt desire to
see people _read_ more (good) code.  Thanks, Steve.

> The thinking about little boxes and labels that you do in C can be
> trick[i]er than the equivalent little boxes and labels in BASIC,
> because there are more things you can do in C.  But it doesn't have
> to be as complicated as it is often made out to be.  And stay away
> from the hardware terminology!

I found the text I deleted above this paragraph well written and
argued, but here I must voice some concern over your recommendation.
Pointers _are_ addresses, and objects _do_ take up memory, and memory
is what we allocate, it does end, etc.  We even have the _address_of_
operator!  C has a _register_ keyword, etc.  These concepts have to be
tied to their hardware entities, but my advise is to build proper
concepts, not just the "replace `register' with `AX', `BX', etc." way
of thinking you find in some places.  (I explicitly recommended
against one of those places/authors, and the example could well be
construed as a pointer to such places in general.)  I would favor a
description more like "registers are special, very fast memory,
severely limited in quantity, closer to the CPU than other memory,
used by the CPU for intermediate results among other things that
require high speed."  Then some pointers (!) to real life registers on
extant hardware.

C is a language which remains intimate with hardware _concepts_, which
the user must master, but "unwarranted chumminess" with the specific
machine hardware is of course an impediment to real understanding.

I'm sorry if it looked as if I favored hardware specifics over a more
general conceptualization of the topic.  The rest of my article would
have dispelled such an interpretation, I hoped.

--
[Erik Naggum]					     <enag at ifi.uio.no>
Naggum Software, Oslo, Norway			   <erik at naggum.uu.no>