Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!rice!uupsi!sunic!kth.se!ugle.unit.no!nuug!ifi!enag From: enag@ifi.uio.no (Erik Naggum) Newsgroups: comp.lang.c Subject: Re: Can Novices Jump Directly in C? (Books) Message-ID: Date: 10 Feb 91 05:14:58 GMT References: <11929@helios.TAMU.EDU> <1991Feb9.042957.20160@athena.mit.edu> Sender: enag@ifi.uio.no (Erik Naggum) Organization: Naggum Software, Oslo, Norway Lines: 86 In-Reply-To: scs@adam.mit.edu's message of 9 Feb 91 04:29:57 GMT In article <1991Feb9.042957.20160@athena.mit.edu>, Steve Summit writes: > In article , Erik Naggum writes: > >C is not well suited for first time programmers due to its intimacy > >with the hardware. > In article <11929@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] Naggum Software, Oslo, Norway