peregrin@hulaw1.harvard.edu (02/07/91)
Can anyone recommend an introduction to programming book that uses C? I'm not referring to C-For-Pascal-Programmers etc. kind of books. I'm aware that most introduction to programming books use Pascal, Basic, or Scheme as their language, but I haven't seen anybooks that start a novice out directly with C. The purpose of this is to help someone I know who intends to teach an introduction to programming class in C (it was formerly taught in Pascal). I'll post the summary if people will send me e-mail. Thanks, James +----------------------------------------------------------------------------+ + James Peregrino | JPEREGRINO@HBSSTG.HARVARD.EDU + + Programmer/Analyst | PEREGRIN@STIG.HARVARD.EDU + + Science & Technology Interest Group | JPEREGRINO@HBS.HBS.HARVARD.EDU + + Harvard Business School | PEREGRIN@HULAW1.BITNET + + Boston, MA 02163 +-----------------------------------+ + Voice: (617)495-6307 | My opinions are only my own and + + FAX: (617)495-0351 | never H.B.S's. + +----------------------------------------------------------------------------+
enag@ifi.uio.no (Erik Naggum) (02/08/91)
In article <1991Feb6.121722.1@hulaw1.harvard.edu>, James Peregrino writes: > Can anyone recommend an introduction to programming book that > uses C? I'm not referring to C-For-Pascal-Programmers etc. kind of > books. I'm aware that most introduction to programming books use > Pascal, Basic, or Scheme as their language, but I haven't seen > anybooks that start a novice out directly with C. > The purpose of this is to help someone I know who intends to > teach an introduction to programming class in C (it was formerly > taught in Pascal). <opinion> C is not well suited for first time programmers due to its intimacy with the hardware. It's better to learn some assembly language and then "discover" the power of C by a little induction than to be given the crypticity of C to handle in addition to learning what a loop is good for. C is not well suited for first time programmers also for the simple reason that it has far too many ways of doing the same thing, which can be horribly confusing to future programmers. Macros can be very useful for experienced programmers, but they easily "clutter" programs in the eyes and minds of the very young. Redefining part of the language you're learning with a macro has to be deferred to people who miss the opportunity to relieve themselves of some tedium. (Of course, object-like macros (like #define MAXSTRLEN 81) are very useful for ("manifest") constants.) Now, as for Pascal, it's been hailed as such a good introductory language. Bogus! Pascal destroys the mind of hopeful young programmers, and it takes years to un-learn Pascalisms. The same is true, IMHO, of most ALGOL-based languages. Strong typing can be useful if it is not a barrier. Ada has strong typing and has overloading, so does C++. Simula has strong typing but sorely lacks overloading and makes people dependent on "crutches". (I don't think any of these languages are any good for beginners, either.) I know, this doesn't leave much for the introduction-level programmer. When kids begin to learn the alphabet and the language they speak in, they read vastly more than they write. Programmers are encouraged to write a snippet of code as soon as possible. (This is great if you already have something useful to write, but we're not there, yet.) I believe beginner programmers should be given some time to intuit the meaning and expressiveness of good code, handling simple problems, and then go on to read of more elaborate algorithms, still avoiding hairy code and syntax. Programming is not only writing code, but also to write in a way which you can understand and be proud of a week later, and which has a high likelihood of containing only syntactic errors. (Strong typing can be an aid in this respect -- but too much of it, and young programmers get frustrated. Better that they learn to behave themselves than to be forbidden to misbehave.) All of this makes C a difficult language to handle, mainly because of the amount of "new things" to remember, and the multitude of ways of expression. I don't have any experience in teaching "fake languages", but I imagine they'd have to capture the abstractions in programming languages much better than real languages to be of value. Perhaps this is why LISP (Scheme) is such a successful beginner's language? The great thing about LISP is that it's very much a real language, too. Soi-disant fourth-generation languages are the worst things to ever put before the mind of a young programmer, in my mind. Not only do they have a very limited appreciation of the past 30 years of language research, they also limit the field of applicaton to a horrible degree. Maybe I'm too "abstract" for the new programmers, but I've seen so many bright minds be crippled by Pascal that I don't wish to let people experience quite such a bad start. To sum this up, I think, if you let beginners _read_ code, explaining how things work, what kind of syntaxes (grammars) are used, that is, make it much more of a linguistic approach than "algorithms and data structures", they won't be the archetypical "beginners" for more than the first month or so. Ask them to do obviously stupid things on the computer as their first move, and they may remain beginners for years. </opinion> Whatever you do, avoid all books by Herbert Schildt. The poor students will be even more crippled than they would have been with Pascal. Schildt is an author who truly believes the reader is a near-complete idiot, and he also sincerely believes that his book is not going to help him, being as inane in the last as in the first chapter. Yes, I think it's too easy to start off on the wrong track for our future programmers. The MS/PC-DOS world isn't helping them, either. Au contraire! the vast majority of products in this world expect a user with an alarmingly low intelligence and learning ability. My experience is that young programmers are like kids on their first day of school -- eager to learn and so easily frustrated by bad teachers. Except, of course, that programmers are generally more curious and more willing to learn, and dare I say more intelligent?, than most kids -- and other apprentice craftsmen. Aren't there some truly bright programmer who take apprentices and teach them the craft, not trying to impress them with so many bogus "tricks of the trade"? I know I would have spent a few years less in "apprentice" state had there been anyone who could have showed me the (right) way. -- [Erik Naggum] <enag@ifi.uio.no> Naggum Software, Oslo, Norway <erik@naggum.uu.no>
scm3775@tamsun.tamu.edu (Sean Malloy) (02/08/91)
>> Can anyone recommend an introduction to programming book that >> uses C? I'm not referring to C-For-Pascal-Programmers etc. kind of >> books. I'm aware that most introduction to programming books use >> Pascal, Basic, or Scheme as their language, but I haven't seen >> anybooks that start a novice out directly with C. >> The purpose of this is to help someone I know who intends to >> teach an introduction to programming class in C (it was formerly >> taught in Pascal). > ><opinion> > >C is not well suited for first time programmers due to its intimacy >with the hardware. It's better to learn some assembly language and >then "discover" the power of C by a little induction than to be given >the crypticity of C to handle in addition to learning what a loop is >good for. > 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. I assume that you're wanting to use (probably) Turbo C on PC's. Check out _C Through Design_ by Defenbaugh & Smedley. It's being used for an introductory-level class in C here at Texas A&M (Though prior programming experience is reccommended for these students, this seems to be laziness on the part of the instructor, and not a shortcoming in the book). For hardware background, I'd suggest _Peter Norton's Programmer's Guide to the IBM PC/PS2_ (at least excerpts - students should be familiar with what's available in the BIOS before jumping into some of the more advanced features of C; it makes life easier, and it makes students realize that there's more than one way to do things) -Sean
scs@adam.mit.edu (Steve Summit) (02/09/91)
In article <ENAG.91Feb8021615@holmenkollen.ifi.uio.no> enag@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@helios.TAMU.EDU> scm3775@tamsun.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. I agree that C is not a good first language; unfortunately I don't know of a better one. (C's popularity, applicability, and availability overcome its drawbacks rather too effectively.) 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. 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. 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 ("See how bad this is? Now don't you ever write anything like this!") 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? (Several people will now point out that, like it or not, one has to be able to read bad code, and that books like The C Puzzle Book are therefore Good Things. Perhaps we can avoid having that argument again.) Dave Lebling tells the story of the Zork player who believed that, in every game, you had to press the blue button, flooding the FCD#3 control room, and then hastily fix the leaky pipe with the gunk from the tube that looks like toothpaste before continuing with the rest of the game. How many programmers believe that they have no choice but to write code which depends on the machine they're using, and that rewriting it for other machines is just a fact of life? As Kernighan and Ritchie say, and I am fond of quoting, "if you don't know _how_ [things] are done on various machines, that innocence may help to protect you." 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 char a[5]; and char *p; the expressions a[3] and p[3] generate significantly different code. We can (I think) make a perfectly clear explanation by discussing the abstract machine on which C is based, without appealing to actual hardware terms. The discussion (and, yes, I'm planning on adding it to the FAQ list) goes like this: "When we say char a[5], we are requesting that a place for five characters be set aside, to be known by the name `a'. That is, there is a location named `a' at which five characters can sit. When the compiler sees the expression a[3], it emits code to start at the location `a', move three past it, and fetch the character there. On the other hand, when we say char *p, we are requesting a place which holds a pointer. The pointer is to be known by the name `p', and can point to any char (or contiguous array of chars) anywhere. When the compiler sees the expression p[3], it emits code to start at the location p, fetch the pointer there, add three to it, and finally fetch the character pointed to." 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." 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. I don't want to sound like a knee-jerk C defender; C *is* hard to learn, and the criticism that it is not a good beginner's language is entirely valid. But, next time you try to teach somebody about C (or, if you're still learning, next time you do any reading or work on a program) just think about those little boxes and labels, and don't worry about "the hardware." If you are assigned exercises to Write a program to discover the sizes of the various types on your machine or Explain the behavior of int i = 5; printf("%d %d %d\n", i++, i++, i++ + i++); , refuse to do them. The thinking about little boxes and labels that you do in C can be tricker 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! Steve Summit scs@adam.mit.edu
bangell%peruvian.utah.edu@cs.utah.edu (Bob Angell) (02/09/91)
I too am a rookie C programmer who used a variety of books.....(yes EVEN -C Through Design_ which I thought would be better used for the fire-place this winter) K&R along with other texts have been very useful, however, the only real way to learn any language is to go at it slow and just start using it. There will be times when you forget to open files, etc (C allows even the most stupid of things trick you into believing that they work). If you stick to books like K & R, any from the waite group and even Microsoft Press (I am not affiliated with MS in any way!) they will help you the most as they have done the same for me. Good luck! -Bob- uunet !peruvian.utah.edu!bangell bangell@peruvian.utah.edu
mike (02/10/91)
In an article, scs@adam.mit.edu writes: >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." [...] Generally speaking, I agree with what you posted. However, C students do have to learn about various machine differences, and how to deal with them. I wouldn't say that it should be an objective in the first couple of classes, but better sooner than later. To write portable code, the use of values.h and sys/types.h is essential, and shouldn't be left as an afterthought. One thing I have noticed in C classes is that the educator spends a moderate amount of time on statements and order of evaluation, a _very_ long time on pointers, structures, linked lists, etc., and very little time talking about the importance of portability. The header files are treated like magical black boxes. All of the sample programs include stdio.h, but they never explain to the student _why_ this is done. The fact that machine differences are ignored is a Bad Thing. The student should know _why_ MAXINT on their IBM PC/AT is 32767 and MAXINT on their IBM RT is 2147483647. My feeling is that it _is_ an important aspect of the language, and deserves equal attention. Programmers who lean on black box assumptions (without the foggiest notion of why what they are doing works) are not good programmers. -- Michael Stefanik | Opinions stated are not even my own. Systems Engineer, Briareus Corporation | UUCP: ...!uunet!bria!mike ------------------------------------------------------------------------------- technoignorami (tek'no-ig'no-ram`i) a group of individuals that are constantly found to be saying things like "Well, it works on my DOS machine ..."
py198723@academ01.mty.itesm.mx (Jesus Eugenio Sanchez) (02/10/91)
peregrin@hulaw1.harvard.edu writes: > Can anyone recommend an introduction to programming book that uses C? >I'm not referring to C-For-Pascal-Programmers etc. kind of books. I'm aware >that most introduction to programming books use Pascal, Basic, or Scheme as >their language, but I haven't seen anybooks that start a novice out directly >with C. The problem with the approach you're trying to do is that C is definitely *not* a language for novice programmers. You have to know all about functions, data structures, and all that parafernalia. So, perhaps you have no choice: first learn Pascal, and then C. Not the other way around. Eugenio Sanchez py198723@academ01.mty.itesm.mx
john@nereid.jpl.nasa.gov (John Veregge) (02/10/91)
peregrin@hulaw1.harvard.edu writes: > Can anyone recommend an introduction to programming book that uses C? >I'm not referring to C-For-Pascal-Programmers etc. kind of books. I'm aware >that most introduction to programming books use Pascal, Basic, or Scheme as >their language, but I haven't seen anybooks that start a novice out directly >with C. Actually I learned both C and pascal (and fortran) the same quarter at UC San Diego. I am no genius (Hell, I wasn't even smart enough to stay in in school!) but I can program well and most of what I know came from books and magazines, not experience or classes. My first C book was "A Book on C" by Al Kelly and Ira Pohl. It was an excellent book that I still enjoy reading. The authors made no assumptions, and the text flows almost like well written prose. It is a very nice beginners book. A good second book (or companion text) is "The C Companion" by Allen Holub. This book presumes prior knowledge of C, but is written to further explain the more esoteric and powerful aspects of C to beginners. There is a presumption that the book's audience is conversant, but not fully fluent in C. Back then I did not understand how pointers work, since the concepts were quite alien to me. After reading this book I was able to re-write a quicksort program from my C class and code away all the array offsets into pointer in/decrements. This may sound trivial, but try recalling when you were a beginner, I'll bet pointers were not so trivial to you then. This book discusses the tools we use (compiler, linker, make, etc), binary arithmetic, assembly language (using a pseudo code), pointers, advanced pointers, recursion, programming style, debugging, and an analysis of printf(). I cannot recommend these two books enough. I can also recommend many more, but you did stipulate books for the rank beginner. {-: I would (as a final gasp) compare "A Book On C" to "Oh Pascal". The differences are that the pascal text is wordy, humorous, and moves at a slower pace. I prefered the pace of the C text. I think the pascal text is one of, if not the, best beginning programming textbooks. But, I did find the pace of it a might slow. Of course, your mileage may differ. -- John R Veregge Section 348 - Flight Command and Data Jet Propulsion Laboratory Management (Technology Development) Calif Institute of Technology Mail stop: T1704, Office: T1704-P 4800 Oak Grove Drive Phone: (818) 354-0511, FAX: 393-4494 Pasadena, CA, USA 91109 john@triton.jpl.nasa.gov
enag@ifi.uio.no (Erik Naggum) (02/10/91)
In article <1991Feb9.042957.20160@athena.mit.edu>, Steve Summit writes: > In article <ENAG.91Feb8021615@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@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@ifi.uio.no> Naggum Software, Oslo, Norway <erik@naggum.uu.no>
enag@ifi.uio.no (Erik Naggum) (02/10/91)
In article <1991Feb8.221802.22573@hellgate.utah.edu>, Bob Angell writes: > K&R along with other texts have been very useful, however, the only > real way to learn any language is to go at it slow and just start > using it. There will be times when you forget to open files, etc (C > allows even the most stupid of things trick you into believing that > they work). Not to be nasty, but my point is that a little more exposure to C code before writing any would be a Good Thing. Understanding C code written by others should be more rewarding than writing your own more or less meaningless example programs, I think. It's like reading a difficult math text and suddenly grasping something, as opposed to sit down and figure out differential calculus just because you want to design a tackle with rope and pulleys. The latter can be practical and immensely rewarding, but you're going to spend some time sweating, much more than you would need to do if you listened to the people who figure it out before you. (Of course, to solidify your new knowledge, practice is needed!) Maybe my basic complaint is that programmers refuse to learn from the experience of prior actors in the field, or that that is the way the subject is approached. A few years ago, I met a very bright girl who wanted to become an author, and almost everything she did was motivated with "I need to read (about) this because I will need it to become an author." It was pure delight to watch her progress. She asked me how she could approach my field of interest (programming languages, communications, text processing, standardization), and I was not able to find any material which would enable her to read about any of these topics with the intent to understand their nature rather than their minute details. Such books exist in almost all the other fields I've played (economics, finance, linguistics, psychology, philosophy, marketing, law, ...). Perhaps this is just too young a discipline, yet. ...just lamenting, I guess. -- [Erik Naggum] <enag@ifi.uio.no> Naggum Software, Oslo, Norway <erik@naggum.uu.no>
gwyn@smoke.brl.mil (Doug Gwyn) (02/11/91)
In article <ENAG.91Feb10063530@holmenkollen.ifi.uio.no> enag@ifi.uio.no (Erik Naggum) writes: >... I was not able to find any >material which would enable her to read about any of these topics with >the intent to understand their nature rather than their minute details. Such books do exist. The one I most liked was Ted Nelson's "Computer Lib/Dream Machines", in its original form (not so much the recently issued new edition). Your concern is a standard problem for the "technical" disciplines; introductory textbooks invariably assume that "somehow" one has already made an irreversible commitment to study hard to become a professional in the field, so they plow into details with insufficient motivation. The books that try to serve as "X for Poets", on the other hand, try to avoid using even the level of mathematics that is supposedly taught in our public schools, even when there is no good substitute for some simple mathematics. Thus a large segment of the non-technical populace comes to think that the technical areas proceed by the same sort of fuzzy reasoning that dominates their fields, leading to such absurdities as taking "it hasn't yet been shown that doing Y does not destroy the ecology" as all the evidence they need to condemn doing Y.
kers@hplb.hpl.hp.com (Chris Dollin) (02/11/91)
mike@bria writes:
................................................ To write portable
code, the use of values.h and sys/types.h is essential, and shouldn't
be left as an afterthought.
Use "values.h" or "sys/types.h" on *my* machine [*1], and your code won't
compile at all; I have a plain ANSI C compiler, and neither of those names
appear to be in the standard.
Is their general agreement on the contents of these headers, and some formal or
informal method for propagating them? [Or am I unwitting about to start the
Great [Bb]ool{ean} Wars again?]
[*1] An Acorn Archimides (A440) running RISC OS 2.
--
Regards, Kers. | "You're better off not dreaming of the things to come;
Caravan: | Dreams are always ending far too soon."ekalenda@cup.portal.com (Edward John Kalenda) (02/12/91)
peregrin@hulaw1.harvard.edu writes: > Can anyone recommend an introduction to programming book that uses C? > I'm not referring to C-For-Pascal-Programmers etc. kind of books. I'm aware > that most introduction to programming books use Pascal, Basic, or Scheme as > their language, but I haven't seen anybooks that start a novice out directly > with C. I must differ with all the other postings about C being a poor language for the first time programmer to learn. It is a complicated language, IF you dump all the features on the student at once. I have successfully taught several people with NO programming experience the C language. The trick is to convince them the computer will not do what you want it to do, only what you tell it, and you must tell it in GREAT detail. Most of the time I only use the K&R white book and the runtime reference manual that goes with the compiler in use. "Learning to Program in C" by Thomas Plum (Plum Hall, Inc. ISBN 0-911537-00-7) is not bad. Teach them the basic constructs, add structures about 2/3 through the class, spend the last two weeks discussing the power features like pointer arithmatic (sp?), passing addresses of scalers to functions, hardware details like short/int/long relative sizes, unions, typedefs, pre-processor macros, and mixed language programming. They can always get into the stuff that will confuse them in an intermediate C class. Ed ekalenda@cup.portal.com
karl@ima.isc.com (Karl Heuer) (02/13/91)
In article <KERS.91Feb11094224@cdollin.hpl.hp.com> kers@hplb.hpl.hp.com (Chris Dollin) writes: >mike@bria writes: >>To write portable code, the use of values.h and sys/types.h is essential, > >Use "values.h" or "sys/types.h" on *my* machine [*1], and your code won't >compile at all; I have a plain ANSI C compiler, and neither of those names >appear to be in the standard. > >Is their general agreement on the contents of these headers...? <sys/types.h> is defined by the POSIX standard. Types that are useful to a pure ANSI C program are already defined in ANSI headers (e.g. time_t in <time.h>), so there's no need for <sys/types.h> here. And you should use <limits.h> rather than <values.h> if you want portability.% Karl W. Z. Heuer (karl@ima.isc.com or uunet!ima!karl), The Walking Lint ________ % Even on a pre-ANSI system. There are PD configuration tools that will build <limits.h> for you.
marwk@levels.sait.edu.au (02/13/91)
In article <39182@cup.portal.com>, ekalenda@cup.portal.com (Edward John Kalenda) writes: > peregrin@hulaw1.harvard.edu writes: >> Can anyone recommend an introduction to programming book that uses C? >> I'm not referring to C-For-Pascal-Programmers etc. kind of books. I'm aware >> that most introduction to programming books use Pascal, Basic, or Scheme as >> their language, but I haven't seen anybooks that start a novice out directly >> with C. > > I must differ with all the other postings about C being a poor language > for the first time programmer to learn. It is a complicated language, > IF you dump all the features on the student at once. I have successfully > taught several people with NO programming experience the C language. The > trick is to convince them the computer will not do what you want it to do, > only what you tell it, and you must tell it in GREAT detail. > > Most of the time I only use the K&R white book and the runtime reference > manual that goes with the compiler in use. "Learning to Program in C" by > Thomas Plum (Plum Hall, Inc. ISBN 0-911537-00-7) is not bad. > > Teach them the basic constructs, add structures about 2/3 through the class, > spend the last two weeks discussing the power features like pointer > arithmatic (sp?), passing addresses of scalers to functions, hardware > details like short/int/long relative sizes, unions, typedefs, pre-processor > macros, and mixed language programming. They can always get into the stuff > that will confuse them in an intermediate C class. > > Ed > ekalenda@cup.portal.com K&R has got to be the worst book for learning C for a beginner that I have seen! I used it to advance my knowledge, but it gave me headaches years ago when I wanted to learn the language. The book by KELLY and POHL: TUBO C: The Essentials of C programming is one of the best I have ever seen (for the beginner). Its method of explaining programs by dissection is excellent - voluminous details for each line a program. The problems in each chapter are nice and easy adn complement the chapters extremely well. There is no need to use TURBO C as there is very little that pertains to it specifically. I believe there is also a product-nonspecific book available too. Ray -- University of South Australia | Plus ca change, plus c'est la meme chose. P.O. Box 1 | Ghing thien me how, ming thien gung me how. Ingle Farm | Knobs, knobs everywhere, South Australia | just vary a knob to think!
pete@minster.york.ac.uk (02/14/91)
peregrin@hulaw1.harvard.edu writes: > Can anyone recommend an introduction to programming book that uses C? > I'm not referring to C-For-Pascal-Programmers etc. kind of books. I'm aware > that most introduction to programming books use Pascal, Basic, or Scheme as > their language, but I haven't seen anybooks that start a novice out directly > with C. Although it's not a _complete_ beginner's book one of the best intros to C must be Kelley & Pohl's ``C By Dissection'' (Benjamin-Cummings, 86 or 87). It explains everything the novice needs to know to get going on a Unix C environment (dunno if there are other machine-specific versions) in a detailed and clear fashion. I bought it years ago solely because because I couldn't find a copy of K&R, or Kelley & Pohl's ``A Book On C'', but I've since recommended it to several people who wanted to learn C. It's less advanced than either of these - but pretty good for novices and not too bad for experienced programmers moving over to C for the first time. (besides, if your novices get enthusiastic you can always point them at something more useful like Harbison & Steele -- or, preferably, Stroustrup :-)) Pete Fenelon -- Pete Fenelon |JANET: pete@uk.ac.york.minster Dept. of Computer Science|Internet:pete@minster.york.ac.uk University of York |UUCP: {the world}!ukc!minster!pete York Y01 5DD ENGLAND |others: pete%minster.york.ac.uk@nsfnet-relay.ac.uk Tel: +44 904 432714 |Beer of the week:Mitchell's Single Malt Winter Warmer
mike (02/14/91)
In an article, levels.sait.edu.au!marwk writes: >K&R has got to be the worst book for learning C for a beginner that I have >seen! I used it to advance my knowledge, but it gave me headaches years ago >when I wanted to learn the language. I personally found it to be an _excellent_ book when learning C. One of the things that I greatly dislike in many of the C books that are out today is the focus on cute pictures and sayings (here is a how a structure is declared, see the cute little elf holding up the structure in the diagram ...) As it is said, C is not a big language, and is not served well by "big" books that cram page after page of diagrams, flowcharts, etc. etc. ad nauseum. The best companion is K&P's (as in "Pike") "Software Tools". If you can snag some of the old Tool's ratfor goodies as well, more power to you. On the bit about starting out in Pascal vs. starting out in C, I would say that C would give the budding programmer the advantage in life. Agreed, the hill is steeper to climb, but once you're on top, you can definately get a better view of the world. One of the big complaints is that the concept of the pointer is overwhelming to C neophytes. The reason why is because so many other langauges go through great contortions to "insulate" you from the reality of memory and addresses. Feel free to flame on, but IMHO programmers program _machines_. Anything that goes to great lengths to insulate you from the machine is deprivation. It's just a matter of how much deprivation is useful, and how much is not. -- Michael Stefanik | Opinions stated are not even my own. Systems Engineer, Briareus Corporation | UUCP: ...!uunet!bria!mike ------------------------------------------------------------------------------- technoignorami (tek'no-ig'no-ram`i) a group of individuals that are constantly found to be saying things like "Well, it works on my DOS machine ..."
datangua@watmath.waterloo.edu (David Tanguay) (02/14/91)
In article <431@bria> uunet!bria!mike writes: >I personally found [K&R] to be an _excellent_ book when learning C. One of >the things that I greatly dislike in many of the C books that are out today >is the focus on cute pictures and sayings (here is a how a structure is >declared, see the cute little elf holding up the structure in the diagram ...) I, too, very much appreciated K&R's brevity when I first learned C. I think it is a good book to learn C from. It may not be so good to learn programming from. (Which did the original poster want?) >One of the big complaints is >that the concept of the pointer is overwhelming to C neophytes. The >reason why is because so many other langauges go through great contortions >to "insulate" you from the reality of memory and addresses. I originally learned B (although C followed soon thereafter). I never had any problems with the concept of a pointer, or pointer arithmetic: in fact, they seemed quite natural. So I don't think teaching beginners about pointers will be a problem (if they truly are beginners). It may not be the right thing to do (many see pointers as EVIL), but if your students haven't been "poisoned" by Pascal or Basic it should be a fairly easy concept to get across. -- David Tanguay Software Development Group, University of Waterloo
arnold@audiofax.com (Arnold Robbins) (02/15/91)
In article <431@bria> uunet!bria!mike writes: >As it is said, C is not a big language, and is not served well by "big" >books that cram page after page of diagrams, flowcharts, etc. etc. ad nauseum. >The best companion is K&P's (as in "Pike") "Software Tools". If you can >snag some of the old Tool's ratfor goodies as well, more power to you. The "P" is for Plauger, as in P.J. Both the original "Software Tools", and the later "Software Tools in Pascal" should be on *every* serious Unix programmer's bookshelf. Brian Kernighan did write "The UNIX Programming Environment" with Rob Pike, and that book is sometimes referred to as "K&P", but the Software Tools books are usually just referred to by their titles. Not to mention, "The Elements of Programming Style, 2nd Edition", also by Kernighan and Plauger. In general, anything with Brian Kernighan as a co-author is worth buying, and reading, at least twice. -- Arnold Robbins AudioFAX, Inc. | Laundry increases 2000 Powers Ferry Road, #200 / Marietta, GA. 30067 | exponentially in the INTERNET: arnold@audiofax.com Phone: +1 404 933 7612 | number of children. UUCP: emory!audfax!arnold Fax-box: +1 404 618 4581 | -- Miriam Robbins
dave@cs.arizona.edu (Dave P. Schaumann) (02/15/91)
In article <431@bria> uunet!bria!mike writes: >[...] The >reason why is because so many other langauges go through great contortions >to "insulate" you from the reality of memory and addresses. Feel free >to flame on, but IMHO programmers program _machines_. Anything that >goes to great lengths to insulate you from the machine is deprivation. >It's just a matter of how much deprivation is useful, and how much is not. The whole purpose of programming languages is to abstract the details of implementation as much as possible. In any new programming language, three interlocked issues have to be addressed: safety, speed, and expressability. For instance, you can make Pascal more expressable by including an address-of operator (like C's &), but only at the cost of speed. Similarly, C can be made more safe but less expressive by removing the & operator. Index checking yeilds a safety/speed trade-off, and recursion yeilds a speed/expressability trade-off. I would submit that for any language, if you want one of these to be high, you have to sacrifice one or both of the others. Now, to what extent depends on a complex interaction of the current state of compiler theory, available machines, and the skill of the implementor. As we can see, various available languages provide a different compromise of these three parameters: C has speed and expressability at the expense of safety, while Pascal chooses safety, and to a lesser extend speed, at the expense of expressability. BASIC chooses safety way above the others. Thus, we can see that the abstraction mechanism provided by modern programming languages is a trade off of safety for expressability and safety. The notion that we program machines, IMHO, is wrong. We program algorithms. At it's highest level, no algorithm deals with memory, or addresses, or anything so concrete. At this level, programming is utterly abstract. Now for the average programmer, language choice is merely a matter of "what do I know/what is available?". For a serious programmer/computer scientist, language choice is a matter of "what fits the problem". >Michael Stefanik | Opinions stated are not even my own. >Systems Engineer, Briareus Corporation | UUCP: ...!uunet!bria!mike -- Dave Schaumann | DANGER: Access holes may tear easily. Use of the access | holes for lifting or carrying may result in damage to the dave@cs.arizona.edu | carton and subsequent injury to the user.
dave@cs.arizona.edu (Dave P. Schaumann) (02/15/91)
In article <860@caslon.cs.arizona.edu> dave@cs.arizona.edu (Dave P. Schaumann) writes: >[...] >For instance, you can make Pascal more expressable by including an address-of >operator (like C's &), but only at the cost of speed. [...] ^^^^^ Oops. This should have been "safety" ------------| -- Dave Schaumann | DANGER: Access holes may tear easily. Use of the access | holes for lifting or carrying may result in damage to the dave@cs.arizona.edu | carton and subsequent injury to the user.
gwyn@smoke.brl.mil (Doug Gwyn) (02/15/91)
In article <431@bria> uunet!bria!mike writes: >The best companion is K&P's (as in "Pike") "Software Tools". Undoubtedly there will be other corrections to this, but as proud owner of autographed copies of these books I can tell you definitively that "Software Tools" is by Kernighan and Plauger. Kernighan and Pike's book is "The UNIX Programming Environment". I agree that they are excellent, but they serve different audiences. "Software Tools" was published when access to C and UNIX was not widespread, in an attempt to bring the power of the UNIX environment and toolkit philosophy to the "rest of us". It made Fortran tolerable by introducing the RatFor language and a preprocessor that turned RatFor into ordinary Fortran. A "Software Tools Users' Group" appeared on the scene and helped make such tools widely available. The need for RatFor these days is much less, since C is widespread now, although the UNIX toolkit approach is still not as prevalent as it deserves to be. A later book by Kernighan and Plauger, "Software Tools in Pascal", was essentially a rewrite of the earlier "Software Tools" using Pascal instead of Ratfor (and of course omitting the Ratfor preprocessor implementation chapter). There is no "Software Tools in C", which would be close to publishing some of the UNIX source code, although I am sure such a book would be welcome. "The UNIX Programming Environment" is targeted specifically at UNIX application developers, with considerable emphasis on exploiting existing tools.
mike (02/16/91)
In an article, cs.arizona.edu!dave (Dave P. Schaumann) writes: >In article <431@bria> uunet!bria!mike writes: >>[...] The >>reason why is because so many other langauges go through great contortions >>to "insulate" you from the reality of memory and addresses. Feel free >>to flame on, but IMHO programmers program _machines_. Anything that >>goes to great lengths to insulate you from the machine is deprivation. >>It's just a matter of how much deprivation is useful, and how much is not. > >The whole purpose of programming languages is to abstract the details of >implementation as much as possible. In any new programming language, three >interlocked issues have to be addressed: safety, speed, and expressability. This is true enough. >Thus, we can see that the abstraction mechanism provided by modern programming >languages is a trade off of safety for expressability and safety. The notion >that we program machines, IMHO, is wrong. We program algorithms. At it's >highest level, no algorithm deals with memory, or addresses, or anything so >concrete. At this level, programming is utterly abstract. I would think of it terms of "conceptualizing" algorithms, not "programming" them. When I write a program, I am "communicating" with a machine (or more than machine), asking it to do some activity on my behalf. The algorithm is the _way_ that I ask, not the specifically the act of asking in of itself. 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. Steve Jobs has made comments that computers should be like telephones; everyone has one, and it's treated like a magical black box by most. This is fine for the public at large, but not for programmers. Ultra-specialization is simply an excuse for ignorance. Obviously not everyone can know everything about everything, but at least a vague idea is a start in the right direction. Encountering students who only think in terms of variables and functions is somewhat disquieting. Especially when that have no idea what the difference is between stack, bss, and data space. A while ago, I was talking to a person who was completely confused over this: int (*some_func)(); some_func = some_extern_func; some_func(arg); Since 'some_func' was not the name given to any function in the program, he was completely lost on how it could be used. Having your head so deeply entrenched in the lofty clouds of algorithms, not knowing _how_ what you are doing works, is like being able to do differential equations but needing a calculator to help to add a column of numbers. >Now for the average programmer, language choice is merely a matter of "what do >I know/what is available?". For a serious programmer/computer scientist, >language choice is a matter of "what fits the problem". Acutally, I would think that language choice depends on what your _employer_ uses for a language (unless you're self-employed, that is). You made some excellent points, and I agree with them. However, lets not become _too_ abstract and disasociate ourselves from the machine in favor of some purely conceptual utopia. >Dave Schaumann | DANGER: Access holes may tear easily. Use of the access > | holes for lifting or carrying may result in damage to the >dave@cs.arizona.edu | carton and subsequent injury to the user. -- Michael Stefanik, MGI Inc., Los Angeles| Opinions stated are not even my own. Title of the week: Systems Engineer | UUCP: ...!uunet!bria!mike ------------------------------------------------------------------------------- Remember folks: If you can't flame MS-DOS, then what _can_ you flame?
fu043@zeus.unomaha.edu (02/17/91)
[a lot of previous discussion deleted] > > K&R has got to be the worst book for learning C for a beginner that I have > seen! I used it to advance my knowledge, but it gave me headaches years ago > when I wanted to learn the language. > > The book by KELLY and POHL: TUBO C: The Essentials of C programming > is one of the best I have ever seen (for the beginner). > > Its method of explaining programs by dissection is excellent - voluminous > details for each line a program. > > The problems in each chapter are nice and easy adn complement the chapters > extremely well. > > There is no need to use TURBO C as there is very little that pertains to > it specifically. I believe there is also a product-nonspecific book > available too. > > Ray > -- > University of South Australia | Plus ca change, plus c'est la meme chose. > P.O. Box 1 | Ghing thien me how, ming thien gung me how. > Ingle Farm | Knobs, knobs everywhere, > South Australia | just vary a knob to think! I am not a novice, but I am a novice to C. I'm currently enrolled in an O/S course in which I am required to write in C, and the recommended C book we use seems to be exactly what the original poster is looking for. It is called "A Book on C" (second edition) and was written by Al Kelley and Ira Pohl. The book does not presuppose any prior knowledge of programming, and starts out with the very basics - yet it is organized in such a way that anyone with prior experience (like me) could look up directly what they wanted to know. The sample programs are quite simple, with excellant explanations. I also very much like the fact that there are optional sections dealing with some UNIX and Turbo C fundamentals, if one of those is the platform that C is running on. I would wholeheartedly recommend this book to be used for an INTRO I and/or INTRO II programming curriculum. I wish my own school had used it instead of having Pascal for its intro courses. The ISBN number is 0-8053-0060-0. Jim McMahon
gwyn@smoke.brl.mil (Doug Gwyn) (02/17/91)
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.