Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!spool.mu.edu!sdd.hp.com!wuarchive!hsdndev!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.lang.c
Subject: Re: Can Novices Jump Directly in C? (Books)
Message-ID: <15224@smoke.brl.mil>
Date: 16 Feb 91 20:14:52 GMT
References: <431@bria> <860@caslon.cs.arizona.edu> <444@bria>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 44

In article <444@bria> uunet!bria!mike writes:
>My point, however, had more of a religious tinge.  I fear that we have been
>training programmers to think _only_ in the lofty, abstract concepts of
>"lists", "structures", "objects", etc.  IMHO, this is half a progammer.  Yes,
>you need to be able to conceptualize and implement these algorithms, but
>you should also know _how_ the machine is doing it.

I think there is some merit to both, but "should" is a useless assertion
unless you're prepared to show why, i.e. what it would accomplish.  I
think many people are concerned that an over-emphasis on the machine-
architectural aspects of C programming has produced a crop of programmers
who produce unnecessarily unportable code, which is not simply an
aesthetic issue but has considerable practical impact.

My advice would be that the expert C programmer should, in almost all
circumstances, understand SEVERAL ways in which the code could actually
be realized as the outcome of reasonable compilation in a variety of
radically different system environments.  Understanding the probable
practical impact of his code, he should then not worry about optimizing
it for any PARTICULAR architecture, but rather simply be comfortable
with its general level of performance in ANY reasonable environment.
This frees the programmer to concentrate on the really important
design and implementation issues, which are of a more abstract nature.

>	int	(*some_func)();
>Since 'some_func' was not the name given to any function in the program,
>he was completely lost on how it could be used.

I don't know what the fellow's conceptual problem was, but the name of
a pointer variable should be clearly distinguishable from other names
that can be used to access specific pointed-to contents, purely from an
abstract understanding of these issues.  Indeed, in the Good Old Days
we used to use pointer abstractions in languages such as Algol quite
successfully without having to understand anything about the details
of any implementation.  While it was entertaining and instructive to
learn something about, say, the manner of employing the unusual
features of the Burroughs B5700 architecture to support high-level
languages, it was normally not essential that one know these details
in order to program effectively.

I would agree that a professional programmer who does not know
anything about how high-level language constructs are mapped onto
machine architectures exhibits a serious deficiency in the breadth of
his training.  There are numerous books that can be used to remedy this.