Peter@adm.UUCP (01/13/87)
I am currently finishing up a new text book on C with a colleague of mine and we just received the last of several technical reviews. This particular reviewer makes some statements that we find hard to accept. However, we're just two people, so we decided to get some opinions from other C programmers. Below is a list of some his statements. Is this guy for real? Your comments would be greatly appreciated. Incidentally, the text is not an intro text, it assumes the reader has finished a course in Pascal. "... 95% of all C programmers couldn't give you a good explanation of the term lvalue..." "... Switch/case could be classified as rarely used and should be kept till later. "... very few C programmers know much about sizeof..." "... 99% of all professional C programmers have no idea what typedef is all about, couldn't care less and probably won't ever need it." "... 99% of all professional C programmers have no idea what the comma operator is all about, couldn't care less and probably won't ever need it." "... Leave the comma operator altogether. An intro book is no place for obscure and unmaintainable tricks..." "... Pointers to functions ... few C programmers understand them or would ever need them..." "... a C programmer never needs to know what a byte is..."
jpn@teddy.UUCP (John P. Nelson) (01/14/87)
I sure wish I could have replied to this article, but the Author's news software generated a return address that was unusable. I had the choice of replying to "brl-adm!news or "adm!Peter Steele - Acadia\@". Peter, please repost, and include a return address!
chris@mimsy.UUCP (Chris Torek) (01/14/87)
In article <2313@brl-adm.ARPA> Peter Steele - Acadia writes: [You did not include a return address, and the info-c -> comp.lang.c gateway consumed any useful approximations; hence the followup.] >This particular reviewer makes some statements that we find hard >to accept. ... Is this guy for real? I wonder. >"... 95% of all C programmers couldn't give you a good >explanation of the term lvalue..." That might well explain much of the code we have seen in comp.lang.c. :-) The term itself may be somewhat obscure, but the concept is very important in C (and many other languages). >"... Switch/case could be classified as rarely used and should be >kept till later. I count 80 occurrences of `switch' in one part of a 4.3BSD-beta kernel. The cases for these (excluding the code under them) make up another 374 lines. There are a total of 30829 lines in this section of code; that works out to about 1.5% of the source lines, including all comments. This is certainly rarer than, say, `if'. But there are only 177 `while's. Should these, too, be classified as `rarely used'? >"... very few C programmers know much about sizeof..." Again, that might explain.... One cannot even use malloc() without sizeof(). >"... 99% of all professional C programmers have no idea >what typedef is all about, couldn't care less and probably >won't ever need it." #defines can replace typedefs in many instances, but not all: typedef char name[5]; typedef name *(*pfnstring)(); pfnstring table[128] = { ... }; /* vs. char (*(*table[128])())[5] = { ... }; */ Using `typedef int (*pfn)()' has helped keep the sanity of many a programmer trying to create a table of function pointers. >"... 99% of all professional C programmers have no idea >what the comma operator is all about, couldn't care less and >probably won't ever need it." That might explain.... >"... Leave the comma operator altogether. An intro book is no >place for obscure and unmaintainable tricks..." It is true that one never needs a comma operator. It is also true that, given a subtract operator, one needs no add operator. Comma may not be as useful as add, but *any* serious C language tutorial should not neglect *any* operator. >"... Pointers to functions ... few C programmers understand >them or would ever need them..." Perhaps few understand them, but they make a world of difference between C and Pascal. It is not possible to `send messages' to `objects' in Pascal; using function pointers, it *is* possible to do this in C. This is immensely useful. Using pointers to functions perhaps cut in half the size of a 68000 disassembler someone here was writing. The result is much clearer as well. A large number of Unix utilities use function pointers. Dynamic loading requires function pointers. Some specific uses may be esoteric. The concept is not. >"... a C programmer never needs to know what a byte is..." Probably true, given that few agree as to what a byte is anyway. Six bits? Eight? Nine? But a C programmer should know that these are common sizes for the `char' datatype, and that if a machine *has* a `byte' type, `char' is probably implemented using it. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) UUCP: seismo!mimsy!chris ARPA/CSNet: chris@mimsy.umd.edu
bryan@druhi.UUCP (BryanJT) (01/14/87)
In article <2313@brl-adm.ARPA>, Peter@adm.UUCP writes: > I am currently finishing up a new text book on C with a colleague > of mine and we just received the last of several technical reviews. > This particular reviewer makes some statements that we find hard > to accept... As a professional C programmer, I thought I'd give you my "off the cuff" analysis. > "... 95% of all C programmers couldn't give you a good > explanation of the term lvalue..." I'd be the first to admit that this might be true (I can't define it personally in a way that makes any sense). All the more reason to spend time talking about what it means! > "... Switch/case could be classified as rarely used and should be > kept till later. This, on the other hand, is total nonsese. Get it in there early, especially for those Pascallers who remember "case ... of ..." > "... very few C programmers know much about sizeof..." This is also nonsense. Sizeof() is an important feature of the language, especially if you want to do dynamic memory allocation. > "... 99% of all professional C programmers have no idea > what typedef is all about, couldn't care less and probably > won't ever need it." Total garbage. A very important feature of the language. > "... 99% of all professional C programmers have no idea > what the comma operator is all about, couldn't care less and > probably won't ever need it." > > "... Leave the comma operator altogether. An intro book is no > place for obscure and unmaintainable tricks..." Even if it were true, they're going to see it sometime and had better know about it. Don't sacrifice completeness for "their own good." Anyway, the comma operator is an often-used shortcut. > > "... Pointers to functions ... few C programmers understand > them or would ever need them..." On the contrary, the better an explanation you can provide the more useful your book will be. Pointers to functions are one of the more useful, and least understood, aspects of the language! > "... a C programmer never needs to know what a byte is..." What!!!??? What kind of nonsense is this? -- -------------------------------------------------------------------------- John T. Bryan USENET: ...!ihnp4!druhi!bryan AT&T Information Systems PHONE: (303) 538-5172 12110 N. Pecos, #8C350 QUOTE: I didn't mean what you thought I meant Denver, CO 80234 you said. -------------------------------------------------------------------------- This is a disclaimer: I don't speak for AT&T, and they don't speak for me. --------------------------------------------------------------------------
gordon@cae780.UUCP (Brian Gordon) (01/14/87)
Sorry to post, by my mailer couldn't grok "To: Peter Steele - Acadia" ... In article <2313@brl-adm.ARPA> Peter Steele - Acadia writes: |I am currently finishing up a new text book on C with a colleague of mine and |we just received the last of several technical reviews. This particular |reviewer makes some statements that we find hard to accept. However, we're |just two people, so we decided to get some opinions from other C programmers. |Below is a list of some his statements. Is this guy for real? Your comments |would be greatly appreciated. Incidentally, the text is not an intro text, it |assumes the reader has finished a course in Pascal. | |"... 95% of all C programmers couldn't give you a good explanation of the |term lvalue..." I'd put it at 80%, but I believe it is HIGH in the non-academic world. |"... Switch/case could be classified as rarely used and should be kept till |later. I don't know where you put it, but is is a "lesser used" control structure. |"... very few C programmers know much about sizeof..." Hard to believe. Doesn't everyone HAVE to use it, eventually, when dealing with arrays and/or structures? |"... 99% of all professional C programmers have no idea what typedef is |all about, couldn't care less and probably won't ever need it." Maybe the reviewer has never seen a 100,000+ line system? Or feels that a book at this level is not applicable to that size effort? For a 200 line program, typedef is not NEEDED. |"... 99% of all professional C programmers have no idea what the comma |operator is all about, couldn't care less and probably won't ever need it." Too strong -- but out local coding standard SEVERELY restricts its use for fear that it is too hard for a casual maintainer to interpret. |"... Leave the comma operator altogether. An intro book is no place for |obscure and unmaintainable tricks..." The reviewer has the same worry about maintainability as the author(s) of our coding standard. On the other hand, why argue FOR incompleteness? |"... Pointers to functions ... few C programmers understand them or would |ever need them..." Again, maybe the reviewer has never seen -- or wishes to exclude -- 100,000+ line systems? |"... a C programmer never needs to know what a byte is..." Context dependent statement! Portable C code can be difficult when you make any assumption/requirement on machine characteristics ... FROM: Brian G. Gordon, CAE Systems Division of Tektronix, Inc. UUCP: tektronix!cae780!gordon [or gordon@cae780.CAE.TEK.COM]
dragheb@isis.UUCP (Darius "OPRDRT" Ragheb) (01/14/87)
In article <2313@brl-adm.ARPA> Peter Steele - Acadia writes: >I am currently finishing up a new text book on C with a colleague >of mine and we just received the last of several technical reviews. >This particular reviewer makes some statements that we find hard >to accept. However, we're just two people, so we decided to get >some opinions from other C programmers. Below is a list of some >his statements. Is this guy for real? Your comments would be >greatly appreciated. Incidentally, the text is not an intro >text, it assumes the reader has finished a course in Pascal. > First of all...where do you want these responses to go? Second: who is this reviewer? a person in industry? if so, i hope he shapes up: his attitude is, to say the least, disgusting. In acadamia? if so, he is a fool. >"... 95% of all C programmers couldn't give you a good >explanation of the term lvalue..." Possibly true, but for god's sake, if your book explains it, then what is his gripe! > >"... Switch/case could be classified as rarely used and should be >kept till later. Has this person ever written a program in his life? > >"... very few C programmers know much about sizeof..." > WHAT? almost ALL programmers (i made this statistic up :-) know about sizeof....many assemblers and compilers now have this feature (I mean, non-C compilers are now adding it). >"... 99% of all professional C programmers have no idea >what typedef is all about, couldn't care less and probably He made that statistic up. >won't ever need it." > >"... 99% of all professional C programmers have no idea >what the comma operator is all about, couldn't care less and >probably won't ever need it." > >"... Leave the comma operator altogether. An intro book is no >place for obscure and unmaintainable tricks..." He has a bad attitude: if 99% of the programmers don;t know about it, it is high time a good book was published explaining it. > >"... Pointers to functions ... few C programmers understand >them or would ever need them..." > >"... a C programmer never needs to know what a byte is..." [by the same token, he must agree, then, that a C programmer does not need to know what a register is.....obviously it is not ESSENTIAL, but its like saying a pilot does not need to know what landing gear is: he knows its there, and when he uses it , it works, but knowledge of it might make him a better pilot] HAHAHAA sounds like you made this one up to get back at the guy! HAHAHAHAHA Good one. Is this reviewr a stand up comedian? Why doesn't he come to the Comedy Works here in Denver....he would be a big hit. HHAHAHAHA Well, I am really not sure if the original posting was a joke or not.....those points did not seem real, but, those are my reactions to the reviewer's statements. What is his problem? Hates people being educated, or what? -- Functionality, Efficiency, Luxury. isis!dragheb | dragheb@isis.cs.du.edu
bcase@amdcad.UUCP (Brian Case) (01/14/87)
Oooooo, I like queries such as this. Since I am a "professional C programmer" (currently writing compilers, mainly), I have definite opinions on the comments from this guy. In article <2313@brl-adm.ARPA> Peter Steele - Acadia writes: >I am currently finishing up a new text book on C with a colleague >of mine and we just received the last of several technical reviews. >This particular reviewer makes some statements that we find hard >to accept. However, we're just two people, so we decided to get >some opinions from other C programmers. > >"... 95% of all C programmers couldn't give you a good >explanation of the term lvalue..." Well, what is a "good explanation." I think I disagree with this though (how about "something that can be dereferenced"? I just looked it up in Aho, Sethi, and Ullman's new dragon book: "... r-values are what we usually think of as 'values,' while l-values are locations." Do I pass?). >"... Switch/case could be classified as rarely used and should be >kept till later. Now wait a minute. This is clearly BS. Where would I be without switch and default? Like, nowhere, man. >"... very few C programmers know much about sizeof..." What is "much about"? I think this is BS as well. This ties in with the "... a C programmer never needs to know what a byte is...." >"... 99% of all professional C programmers have no idea >what typedef is all about, couldn't care less and probably >won't ever need it." Well, I disagree with "have no idea what typedef is all about," but I may agree mildly that they won't use it much. I never use it, but I am very lazy. Frankly, I very rarely see it, and I see a lot of code. But this is no excuse for leaving it out, *especially* if the audience of your book is expected to be PASCAL graduates (they will ask "where are the TYPE statements?"). Besides, being at least exposed to the full language is important. Maybe you shouldn't use it in ALL of the example programs, but.... >"... 99% of all professional C programmers have no idea >what the comma operator is all about, couldn't care less and >probably won't ever need it." Wow, this guy can make lots of strong statements. I have used it, but I try to avoid using it since I find it confusing. I think the "advantage" of having all the initialization (for example) within the parens of the "for" statement is not worth the grunginess of the syntax. Besides, with modern compilers, who knows in what order things will be done. >"... Leave the comma operator altogether. An intro book is no >place for obscure and unmaintainable tricks..." It is part of C. If I used your book, and then later found out about the comma operator, my reaction would be "gee, what a worthless book, it doesn't even document the entire language!" What if the student encounters code with the comma operator? He'll be *forced* to go to a "better" book! You don't have to devote 10 chapters to it.... >"... Pointers to functions ... few C programmers understand >them or would ever need them..." While I don't use them much (maybe ever?), the ability to develop a pointer to a function (and arrays of, and ...) is so powerful that I often ask myself "wonder if I could pass a pointer to a function here." >"... a C programmer never needs to know what a byte is..." Sigh, I wish this were true. And even if it were true, it wouldn't prevent students from *finding out* about the relationship between bytes and words and pointers and structures and etc. I don't know what you said in you book to provoke this comment, but it is probably worth mentioning to C programmers as early as possible that it is quite within the limits of C to write machine-dependent code. At least warning them that they may encounter code which assumes things about "byte" and "word" equalling "char" and "int" respectively is probably in order. bcase
henry@utzoo.UUCP (Henry Spencer) (01/14/87)
My guess is that this reviewer is an academic (obviously he is not a professional C programmer) who learned C a very long time ago and has never used it much or made much effort to keep up to date with the language. Having said that, I should mention my background: I first learned C about 12 years ago and have been working in it ever since, much of the time as a professional C programmer. > "... 95% of all C programmers couldn't give you a good > explanation of the term lvalue..." This is probably true, but the concept is important and needs mention. I see no convenient way to do this without the term. What he probably is thinking of is that experienced C programmers have forgotten the term because they have an intuitive understanding of its implications. True, but irrelevant. > "... Switch/case could be classified as rarely used and should be > kept till later. Nonsense, it's fundamental -- more so than some of the odder control constructs like "continue" and "do{}while()", in fact. > "... very few C programmers know much about sizeof..." How much is there to know? Anyone using malloc should be using sizeof. > "... 99% of all professional C programmers have no idea > what typedef is all about, couldn't care less and probably > won't ever need it." Professional C programmers have to know what typedef is about, since they will be called on to maintain code that uses it someday. There is quite a substantial subset of C programmers, particularly the ones who have been around since pre-typedef days, who very seldom USE typedef. Macros suffice for typedef's most common uses. However, there are certain jobs, such as de-cryptifying complicated declarations, where there is just no adequate substitute. It is important that new C programmers know what typedef is about, even if they don't use it often. > "... 99% of all professional C programmers have no idea > what the comma operator is all about, couldn't care less and > probably won't ever need it." Again, professional C programmers have to know what it's about since they will run into it in other peoples' code someday. The comma operator is not the most useful thing in C by a long shot. It is convenient from time to time, but its real importance comes in very specialized situations. Again, this is something C programmers should at least hear about briefly so that they can read strange code. > "... Pointers to functions ... few C programmers understand > them or would ever need them..." Utter nonsense, there are quite a number of situations where they are both useful and important. Most C programmers have at least a superficial understanding of them, although there are certainly some minefields when it comes to complex declarations involving them (this is one place where typedefs become very useful...). > "... a C programmer never needs to know what a byte is..." He's going to have trouble understanding the full semantics of frequently- used primitives like "read" without some grasp of fundamental memory organization, including the nasty word "byte". People doing limited sorts of programming with all i/o via stdio could get away without it. People doing serious C work, especially systems programming, and especially work requiring reading other peoples' code, need to understand what bytes are and how they tie in with things like read() and fread() and sizeof. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,decvax,pyramid}!utzoo!henry
bet@ecsvax.UUCP (Bennett E. Todd III) (01/14/87)
I couldn't reply via mail (most amusingly munged header I can recall
having seen); that reply can be safely ignored. Sounds like the fellow
who submitted it should have been reading your work to learn C, rather
than attempting to critically review it.
-Bennett
--
Bennett Todd -- Duke Computation Center, Durham, NC 27706-7756; (919) 684-3695
UUCP: ...{decvax,seismo,philabs,ihnp4,akgua}!mcnc!ecsvax!duccpc!bet
BITNET: DBTODD@TUCC.BITNET -or- DBTODD@TUCCVM.BITNET -or- bet@ECSVAX.BITNET
terrorist, cryptography, DES, drugs, cipher, secret, decode, NSA, CIA, NRO.forrest@blia.BLI.COM (Jon Forrest) (01/15/87)
I do freelance technical reviewing for several publishers and have some feel for what goes into such reviews. I think the major reason for your surprise is because the reviewer that examined your book (not me, by the way) may have been including people who program in C on micros in his comments. These people don't always have the same level of experience as Unix (or VMS) hackers. Anyway, I've added a few well chosen comments to those of your reviewer. > > "... 95% of all C programmers couldn't give you a good > explanation of the term lvalue..." > Probably less than 95% but more than 50% > "... Switch/case could be classified as rarely used and should be > kept till later. > Completely wrong > "... very few C programmers know much about sizeof..." > Probably wrong > "... 99% of all professional C programmers have no idea > what typedef is all about, couldn't care less and probably > won't ever need it." > Again, probably less than 99% but more than 50% > "... 99% of all professional C programmers have no idea > what the comma operator is all about, couldn't care less and > probably won't ever need it." > Again, probably less than 99% but more than 50% > "... Leave the comma operator altogether. An intro book is no > place for obscure and unmaintainable tricks..." Depending on how complete your book is intented to be, this may be a good idea. However, C is such a small language that there really is no reason to leave anything out. > > "... Pointers to functions ... few C programmers understand > them or would ever need them..." Completely wrong > > "... a C programmer never needs to know what a byte is..." Completely wrong Jon Forrest ucbvax!mtxinu!blia!forrest
ag0@k.cc.purdue.edu (Colin Jenkins) (01/15/87)
In article <2313@brl-adm.ARPA> Peter@adm.UUCP writes: >I am currently finishing up a new text book on C with a colleague >of mine and we just received the last of several technical reviews. >This particular reviewer makes some statements that we find hard >to accept. However, we're just two people, so we decided to get >some opinions from other C programmers. Below is a list of some >his statements. Is this guy for real? Your comments would be >greatly appreciated. > >"... 95% of all C programmers couldn't give you a good >explanation of the term lvalue..." > >"... Switch/case could be classified as rarely used and should be >kept till later. > >"... very few C programmers know much about sizeof..." > >"... 99% of all professional C programmers have no idea >what typedef is all about, couldn't care less and probably >won't ever need it." > >"... 99% of all professional C programmers have no idea >what the comma operator is all about, couldn't care less and >probably won't ever need it." > >"... Leave the comma operator altogether. An intro book is no >place for obscure and unmaintainable tricks..." > >"... Pointers to functions ... few C programmers understand >them or would ever need them..." > >"... a C programmer never needs to know what a byte is..." Well, personally, I think this guy is pulling your leg. I use the switch/case construct all the time and I also depend heavily on the comma operator in my for loops. I cannot believe that a C programmer doesn't need to know about bytes. Machine dependancies can creep in lots of obscure places, and for C programmers certain implimentation details (like knowing what a byte is) are important to know when writing code that is easily portable. Seriously, the comments made by this programmer(?) make 99% of all C programmers appear as little more than barely inteligent. I have a hard time believing that these were comments made by a real C programmer. Colin
pinkas@mipos3.UUCP (Israel Pinkas) (01/15/87)
In article <2313@brl-adm.ARPA> Peter@adm.UUCP writes: >I am currently finishing up a new text book on C with a colleague >of mine and we just received the last of several technical reviews. >This particular reviewer makes some statements that we find hard >to accept. However, we're just two people, so we decided to get >some opinions from other C programmers. Below is a list of some >his statements. Is this guy for real? Your comments would be >greatly appreciated. Incidentally, the text is not an intro >text, it assumes the reader has finished a course in Pascal. OK. Here goes... >"... 95% of all C programmers couldn't give you a good >explanation of the term lvalue..." Wrong. MOST C programmers that use the language extensively know that an lvalue is anything that may be assigned to. It might be true that many C programmers don't know that it is called an lvalue. But don't let that stop you from teaching your readers that. >"... Switch/case could be classified as rarely used and should be >kept till later. Wrong. Besides being part of the language, case statement are usually a much better form that 'if ... else if ... else' statements. The code is more readable (you can see the test being done because it is on the left margin of the code). Besides, you assume that your readers know PASCAL, which has the CASE statement. (Unless you assume that their PASCAL course was wimpy.) >"... very few C programmers know much about sizeof..." If "we the programmers who call malloc" are a very small minority, I guess that this might be true. But reallistically, since any linked list, binary tree, or dynamic array needs malloc, and since these are always good excersizes (maybe not, but every course I ever heard of had them), you would be wise to discuss sizeof. At lease enough to do the above and be comfortable. >"... 99% of all professional C programmers have no idea >what typedef is all about, couldn't care less and probably >won't ever need it." I would say closer to 50%, seeing as how many people are learning C on micros and many of those compilers don't have typedef. But since it has been around since K&R wrote "The Bible", you just can't ignore it. maybe you should put it in one of the later chapters along with sizeof, malloc, and the low-level I/O calls. >"... 99% of all professional C programmers have no idea >what the comma operator is all about, couldn't care less and >probably won't ever need it." > >"... Leave the comma operator altogether. An intro book is no >place for obscure and unmaintainable tricks..." Wrong. K&R introduce it relatively early. Ans since it is nice to be able to have 2 counters going in for loops (or 2 pointers, you get the idea), I would introduce it. Just after I introduce pointers. Then I would write all the versions of strcmp() that K&R do. (Or some other function like that.) >"... Pointers to functions ... few C programmers understand >them or would ever need them..." I would say that most C programmers never need to use them. But there are some times that they are necessary. >"... a C programmer never needs to know what a byte is..." Unless he wants to do something useful. It sounds like you got a turkey of a reviewer. Either that, or (s)he didn't know what (s)he were talking about. Comments like the ones made tend to indicate that the speaker had a C cource in college, and hasn't had much use for the language since. Since your readers already know how to program a structured language, I would say that you might teach them what you can do in C that can't be done in PASCAL. (Besides strings, bitwise operators, and such.) The only thing that is not done easily in C is SETS, but those can be simulated with enums or fields. Good luck with your book. -Israel -- ---------------------------------------------------------------------- UUCP: {amdcad,decwrl,hplabs,oliveb,pur-ee,qantel}!intelca!mipos3!pinkas ARPA: pinkas%mipos3.intel.com@relay.cs.net CSNET: pinkas%mipos3.intel.com
jwhitnel@csi (Jerry Whitnell) (01/15/87)
In article <2313@brl-adm.ARPA> you write: >some opinions from other C programmers. Below is a list of some >his statements. Is this guy for real? Your comments would be >greatly appreciated. Incidentally, the text is not an intro >text, it assumes the reader has finished a course in Pascal. > >"... 95% of all C programmers couldn't give you a good >explanation of the term lvalue..." False. I would guess 1/3 to 1/2 could give you a definition. 95% couldn't give you a complete and technically correct definition. > >"... Switch/case could be classified as rarely used and should be >kept till later. False. Switch statements are a very useful and very commonly used construct. I would guess 90+% of all C programs use at least one. > >"... very few C programmers know much about sizeof..." False. Most C programmers know and understand the uses of sizeof (even if some don't use it when they should!) > >"... 99% of all professional C programmers have no idea >what typedef is all about, couldn't care less and probably >won't ever need it." False. Most C programmers do know what typedef is, even though the construct is relativly new to the language. This is becauase most C programmer's are also relativly new. > >"... 99% of all professional C programmers have no idea >what the comma operator is all about, couldn't care less and >probably won't ever need it." Probably true. I use it, but wouldn't miss it if it wasn't there. > >"... Leave the comma operator altogether. An intro book is no >place for obscure and unmaintainable tricks..." > True. >"... Pointers to functions ... few C programmers understand >them or would ever need them..." False. Anyone who has programmed the Macintosh needs to understand them and use them. Pointers to functions are a necessary and useful tool for any professional programmer. > >"... a C programmer never needs to know what a byte is..." False. Understanding the byte is necessary to understand the technicques of writing truly machine independent code. My answers are based on 8+ years of C programming and of reading 1000's of C programs written by all levels of programmers.
holtz@sdcsvax.UCSD.EDU (Fred Holtz) (01/15/87)
The quotes you included were all very much out of line, in my not so humble opinion. I'm no C wizard, but have on some occasion used all the language items covered. As for what an lvalue is - you might as well not discuss pointers at all if you don't have some concept of lvalue. And in order to use malloc one must understand the units being allocated, i.e. bytes (usually). Sizeof fits naturally into this theme. It makes me wonder how biased against C (and C programmers) the reviewer was... Fred Holtz holtz@sdcsvax.UCSD.EDU -- Fred Holtz holtz@sdcsvax.UCSD.EDU
socha@drivax.UUCP (Henri J. Socha (socha)) (01/15/87)
>"... 95% of all C programmers couldn't give you a good >explanation of the term lvalue..." How true. Now, before you disagree, ask programmers who do not read comp.lang.c (or similar). To them C is a tool, just another language to write a programme in. >"... Switch/case could be classified as rarely used and should be >kept till later. >"... very few C programmers know much about sizeof..." Well, I must disagree with this. >"... 99% of all professional C programmers have no idea >what typedef is all about, couldn't care less and probably >won't ever need it." There are those who cut their C teeth on small machine with OLD compilers (read not full K&R) that did not have typedef! There is lots of code here with: #define ATYPE struct astruct ATYPE { ... /* field definitions */ }; ATYPE aVariable, *pointToStruct; Notice how typedef has been worked around. (Not couldn't care less but, wouldn't do better or didn't know better.) As for "Won't ever need it", anytime they (you) use a struct you should use a typedef. My Pascal (AlgolW, WATFIV-S) background is showing. Define your constants, then your types, then your globals, etc. (You should be putting all new programmes in full ANSI C compatibility mode. it can only help in making sure everything is right. How many times did that bug turn out to be a wrong function declaration or passed paramter?????) >"... 99% of all professional C programmers have no idea >what the comma operator is all about, couldn't care less and >probably won't ever need it." >"... Leave the comma operator altogether. An intro book is no >place for obscure and unmaintainable tricks..." This is one obfuscation that I wish did not exist with one exception (inside "for" expressions). Those who use "if (bool) expr, expr, expr;" deserve bugs. >"... Pointers to functions ... few C programmers understand >them or would ever need them..." Sad that they do not understand another of C's great features. Be sure to push this one in the book. Many assembly language programmers know and use this. Any time you have a table containing numbers (in one field) that is then used to switch with, you could have had a table of pointers to functions and eliminated the switch/driver overhead. I know of an I/O subsystem that for its "file pointer" used a pointer to a structure of function pointers. It was easily extensible, logical, and the FASTEST I/O package on the machine. Part of its speed was that when you wanted to write/read/etc. you directly called the disk/printer/display I/O routine desired without having to go through some file pointer -> device driver -> I/O routine overhead. It was Object Oriented! >"... a C programmer never needs to know what a byte is..." Portable software requires such but "need" is the incorrect word. Just listen to the bigendian .vs. littleendian debates in comp.sys.arch(?). Finally, good luck on the book and be sure to use it as a vehicle to educate GOOD programming techniques as well as learning to programme. -- UUCP:...!amdahl!drivax!socha WAT Iron'75 "Everything should be made as simple as possible but not simpler." A. Einstein
tps@sdchem.UUCP (Tom Stockfisch) (01/15/87)
(Email failed, so I posted this even tho there will probably be too many responses) In article <2313@brl-adm.ARPA> >"... 95% of all C programmers couldn't give you a good >explanation of the term lvalue..." I've never heard a *really* good explanation of lvalue, but it is an essential concept to C (to any language?) and should be explained as best one can. If you don't think in terms of lvalues you make mistakes like int a[5]; a = 1; or (int *)b = c; >"... Switch/case could be classified as rarely used... Disprove this by looking at various software projects and doing grep -l switch *.c | wc -l compared to ls *.c | wc -l Or do grep for *.c | wc -l compared to grep switch *.c | wc -l >...[switch should be] kept till later. It is conceivable you might want to save the switch statement until you've shown some sample programs if you're really keen on giving some examples before getting very far. >"... very few C programmers know much about sizeof..." Every C programmer I know knows about sizeof. Many also have some unfortunate misconceptions about it that it would be good for a textbook to clarify. > >"... 99% of all professional C programmers have no idea >what typedef is all about, couldn't care less and probably >won't ever need it." All C programmers I know know all about typedef. In fact, I would say that *novice* programmers use this feature more than experts. The expert says int *(*f[10])(); and the novice says typedef int *PI; typedef PI (*PFPI)(); PFPI f[10]; >"... 99% of all professional C programmers have no idea >what the comma operator is all about, couldn't care less and >probably won't ever need it." All C programmers I know know about the "," operator. The novices use it for convenience, as in for ( i = 0, j = 0; ...; ++i, ++j ) and the experts use it in macro definitions. Even if you decide never to use it, you MUST know what it's about if you ever maintain anybody else's code. >"... Leave the comma operator altogether. An intro book is no >place for obscure and unmaintainable tricks..." Any book which omits the "," operator is grossly incomplete. >"... Pointers to functions ... few C programmers understand >them or would ever need them..." All C programmers I know understand them and use them. Some have to use typedefs to declare an array of them. >"... a C programmer never needs to know what a byte is..." Impossible to comment on without knowing the context. >Is this guy for real? No. || Tom Stockfisch, UCSD Chemistry tps%chem@sdcsvax.UCSD
foss@ihlpg.UUCP (01/15/87)
: I am currently finishing up a new text book on C with a colleague : of mine and we just received the last of several technical reviews. : This particular reviewer makes some statements that we find hard : to accept. However, we're just two people, so we decided to get : some opinions from other C programmers. Below is a list of some : his statements. Is this guy for real? Your comments would be : greatly appreciated. Incidentally, the text is not an intro : text, it assumes the reader has finished a course in Pascal. : : "... 95% of all C programmers couldn't give you a good : explanation of the term lvalue..." : : "... Switch/case could be classified as rarely used and should be : kept till later. : : "... very few C programmers know much about sizeof..." : : "... 99% of all professional C programmers have no idea : what typedef is all about, couldn't care less and probably : won't ever need it." : : "... 99% of all professional C programmers have no idea : what the comma operator is all about, couldn't care less and : probably won't ever need it." : : "... Leave the comma operator altogether. An intro book is no : place for obscure and unmaintainable tricks..." : : "... Pointers to functions ... few C programmers understand : them or would ever need them..." : : "... a C programmer never needs to know what a byte is..." I think your reviewer likes to think that he/she is in the vast majority of C programmers. In fact, he/she is in a very sad minority and is not qualified to read your *NON* intro textbook.
falk@uxc.cso.uiuc.edu.UUCP (01/15/87)
{re: reviewers comments on book draft}
I've been a 'serious' C programmer for only about a year now and I not only
know all of the concepts listed, but use them regularly (I came from a fortran
environment and find the C constructs particularly refreshing). DON'T PULL
THEM OUT OF YOUR BOOK. We have enough pablum-C books around. Besides, if
nobody puts them in books, its no wonder that they may not get used by the
'mainstream'!
Connie Falk
UUCP: {ihnp4,pur-ee,convex}!uiucdcs!uiucuxc!falk
ARPANET: falk%uiucuxc@a.cs.uiuc.edu CSNET: falk%uiucuxc@uiuc.csnet
ICBM: 40 07 N / 88 13 W
US Mail: Univ of Illinois, CSO, 1304 W Springfield Ave, Urbana, IL 61801
AT&T: 217-333-8050draper@tallis.dec.com (a keyboard? how quaint) (01/15/87)
i don't know who this guy is, but i think he's way off base here. > >"... 95% of all C programmers couldn't give you a good >explanation of the term lvalue..." there's some truth here, but i'd say it's considerably less than 95%, and that even then it's generally a case of knowing "how it works" but not knowing the specific terminology >"... Switch/case could be classified as rarely used and should be >kept till later. in favor of nested if-else's? semantically they may be equivalent and maybe a good compiler/optimizer generates equivalent code, but i find the switch-case to be much clearer (except possibly in some fall-thru case's). all (?) modern procedural languages have some kind of one-out-of-many case statement. >"... very few C programmers know much about sizeof..." how's this guy do portable dynamic memory allocation? >"... 99% of all professional C programmers have no idea >what typedef is all about, couldn't care less and probably >won't ever need it." he must not do much work under unix with <sys/types.h> or in general with complex data structures. (unless he's a fan of always typing "struct foo_struct foo;" or "int *(*function)()") >"... 99% of all professional C programmers have no idea >what the comma operator is all about, couldn't care less and >probably won't ever need it." > >"... Leave the comma operator altogether. An intro book is no >place for obscure and unmaintainable tricks..." first of all, it isn't an intro book. second, it's not an "unmaintainable trick" --- it's a formal part of the language with consistent semantics across implementations. third, it's very useful in many circumstances --- for example in for loops >"... Pointers to functions ... few C programmers understand >them or would ever need them..." this is one of the more powerful features of the language. it lets you, for example, build fully generalized sorting routines where the caller provides a pointer to a comparison function. >"... a C programmer never needs to know what a byte is..." of course s/he does --- if s/he's going to use, or even understand, unions, for example. that's not to say that a byte must always be 8 (or 6 or 9 or . . .) bits. based on how this guy is trying to emasculate c to a mere shadow of itself, he'd probably uses a tractor-trailer truck to go to the corner store for a loaf of bread :^) bruce
keith@oz.UUCP (Keith Crews) (01/15/87)
In article <2313@brl-adm.ARPA> Peter@adm.UUCP writes:
-I am currently finishing up a new text book on C with a colleague
<....>
-"... 95% of all C programmers couldn't give you a good
-explanation of the term lvalue..."
-"... very few C programmers know much about sizeof..."
-"... 99% of all professional C programmers have no idea
-what typedef is all about, couldn't care less and probably
-won't ever need it."
-"... 99% of all professional C programmers have no idea
-what the comma operator is all about, couldn't care less and
-probably won't ever need it."
-"... Pointers to functions ... few C programmers understand
-them or would ever need them..."
I agree with everyone else that the reviewer you got is a turkey, but
he appears to have (inadvertently) made an interesting point - there
are several areas of C that even experienced C programmers do not
understand well. I think that you should emphasize these in your book,
rather than omit them as he seems to imply you should. BTW, his
statement about switch statements being unimportant really stands
out among the others as being particularly ridiculous.cramer@kontron.UUCP (Clayton Cramer) (01/16/87)
> I am currently finishing up a new text book on C with a colleague > of mine and we just received the last of several technical reviews. > This particular reviewer makes some statements that we find hard > to accept. However, we're just two people, so we decided to get > some opinions from other C programmers. Below is a list of some > his statements. Is this guy for real? Your comments would be > greatly appreciated. Incidentally, the text is not an intro > text, it assumes the reader has finished a course in Pascal. > > "... 95% of all C programmers couldn't give you a good > explanation of the term lvalue..." I know *I* couldn't -- all the more reason it belongs in a text on C. > "... Switch/case could be classified as rarely used and should be > kept till later. It sounds like your reviewer is a frustrated BASIC program who learned C and hasn't learned anything since. > "... very few C programmers know much about sizeof..." Nonsense. Same remarks as above. > "... 99% of all professional C programmers have no idea > what typedef is all about, couldn't care less and probably > won't ever need it." COMPLETE NONSENSE -- typedefs and enumerated types are essential to writing maintainable programs in C. > "... 99% of all professional C programmers have no idea > what the comma operator is all about, couldn't care less and > probably won't ever need it." Your reviewer has clearly never written a loop with two independently changing loop variable. Is this guy for real? > "... Leave the comma operator altogether. An intro book is no > place for obscure and unmaintainable tricks..." Comma isn't unmaintainable -- no is it obscure. Someone should probably explain to your reviewer that <stmt> , <stmt> is roughly equivalent to { <stmt>; <stmt>; } in places like a for statment. (BTW: can you say for ({I = 0; J = 0}; I < 20; I++, J--)? > "... Pointers to functions ... few C programmers understand > them or would ever need them..." It's possible to use pointers to functions without understanding them, but you can't write anything but a trivial program without needing pointers to function. > "... a C programmer never needs to know what a byte is..." C != Pascal. I'm sure it's possible to debug a C program without a knowledge of machine architecture, but I shudder to think of it. Let me recommend you ignore your reviewer's remarks. Clayton E. Cramer
mark@ems.UUCP (Mark H. Colburn) (01/16/87)
1. "... 95% of all C programmers couldn't give you a good
explanation of the term lvalue..."
I would say that there may be a fair number of people who do not know
what an lvalue is, however, in order to use pointers, they have to have
the concept of an lvalue down pat. A rose by any other name...
2. "... Switch/case could be classified as rarely used and should be
kept till later.
I would say that this is very wrong. I have seen a lot of switch/case
constructs around. There may be a lot of programmers that do not use
them, prefering to use deeply nested if/then/else structures instead.
This however does not mean that it should not be taught. Programmers
should know the alternatives and use which ever method they prefer.
3. "... very few C programmers know much about sizeof..."
I would say this is wrong. A lot of programmers don't USE the sizeof
'function' when they should, but that does not mean that they do not
know about it. Try {m|c}alloc()'ing a structure without it.
4. "... 99% of all professional C programmers have no idea
what typedef is all about, couldn't care less and probably
won't ever need it."
Once again, I think that this is a case of programmer preference.
Some programmers typedef EVERYTHING. Other programmers do not.
Once again, give the reader a choice, show the alternative and let
them make up their mind what they want to do. A hint, more easily
maintained code can come about due to the use of typedefs. Typedef
bool, or byte comes to mind. However, there are very few things that
can be done with typedef that cannot be done with a #define <typename>
5. "... 99% of all professional C programmers have no idea
what the comma operator is all about, couldn't care less and
probably won't ever need it."
This may or may not be true. I am not altogether clear about the
use of the comma operator. It can be useful in constructs such as
for() and while(), but other than that...
(This is more a personal comment than anything else...)
6. "... Leave the comma operator altogether. An intro book is no
place for obscure and unmaintainable tricks..."
Once again, I don't think it should be left out. It should be taught
so that the reader know what it is when he/she comes across it in code.
Either that or they will sit and scratch their heads when they do, thinking
"That's not legal, is it?..."
7. "... Pointers to functions ... few C programmers understand
them or would ever need them..."
It may be true that few programmers understand them, but that may be
due to the fact that they were never taught them in the first place.
They can be very useful, portable, timesaving and efficient.
8. "... a C programmer never needs to know what a byte is..."
Wrong. Maybe a programmer doesn't need to know what a computer is either?
A writer has to know what paper is before he writes on it. A programmer
needs to know what a byte/word/K is before they write into it. Besides
a programmer that did not know what a byte is would be lost in the work
place.
It sounds as if your reviewer could stand to go back to school. It sounds
like I would not like to have to maintain the code that he wrote if he
does not know what this stuff is. Maybe he just has a low opion of other
programmers or programmer's intellects. I don't know, either way, I don't
think that his comments were valid.
--
Mark H. Colburn UUCP: {rutgers|amdahl|ihnp4}!{dayton|meccts}!ems!mark
EMS/McGraw-Hill ATT: (612) 829-8200
9855 West 78th Street
Eden Prairie, MN 55344sohan@im4u.UUCP (Sohan Ramakrishna Pillai) (01/16/87)
In article XX, some disinformed reviewer writes: >1. "... 95% of all C programmers couldn't give you a good >explanation of the term lvalue..." Probably true in the sense that they cannot give the definition of the term itself. Add me to such a group till I read the manual following the above article. But try asking any C programmer with some experience what kind of "expressions" could be used on the left side of an assignment statement! This sounds like the ancient joke of "Mr.X, at the ripe old age of 40, discovered that he had been talking prose all his life". >2. "... Switch/case could be classified as rarely used and should be >kept till later. !!! >3. "... very few C programmers know much about sizeof..." This, and (2) make me believe that the cross-section of C programmers the reviewer has been dealing with are not representative of all C programmers, but just some naive C users who have just had an introduction to the C language. While it can be shown that the use of switch/case can be avoided, perhaps with a little loss of elegance, by means of nested if-then-else-ifs, the sizeof operator is crucial in importance once you come to dynamic allocation. Unless one thinks of trying to literally add up sizes of structures, by hand. :-) >4. "... 99% of all professional C programmers have no idea >what typedef is all about, couldn't care less and probably >won't ever need it." Typedef is again another of those things you could still write programs without, but it can be useful sometimes. Adds elegance! My guess (from a student perspective!) is that new Pascal->C converts "overuse" it, while old C users "underuse" it. >5. "... 99% of all professional C programmers have no idea >what the comma operator is all about, couldn't care less and >probably won't ever need it." This is another discardable but useful feature. Professional C programmers had better have heard of it. I come under the category of "don't care a lot, but no harm in it". >6. "... Leave the comma operator altogether. An intro book is no >place for obscure and unmaintainable tricks..." Nothing obscure about the comma operator, unless viewed from a Pascal, or yes, FORTRAN/COBOL/something-else perspective, and nothing unmaintainable either, unless the suggesstions made by the reviewer take root and future generations of C programmers do not know the comma operator. So, unless the intro is meant for kindergarten/high-school, the comma operator should definitely be included. >7. "... Pointers to functions ... few C programmers understand >them or would ever need them..." Pointers to functions should not be thrown out of the window so easily. They can be very useful, e.g. the generic sorting routine, as mentioned by someone else too. >8. "... a C programmer never needs to know what a byte is..." In the strict sense, probably true. K&R define a byte only in terms of sizeof in their C manual (the sizeof char = 1). One does not need to know the hardware's definition of a byte exactly to be able to write good, portable C programs. But the concept of a byte as a piece of memory required to hold a character, yes, you need to know that. Sounds like some bureaucrat from the Pentagon did the above review! :-) __ Sohan C. Ramakrishna-Pillai {ihnp4, seismo}!ut-sally!im4u!sohan sohan@im4u.UTEXAS.EDU
gnu@hoptoad.uucp (John Gilmore) (01/16/87)
The reviewer has probably been reading C code written by graduates from the 8088 assembler school of engineering. I hope I'm not the only one who noticed the really *low* quality of public domain software written in C on (non-Unix) micros. (Code first written on Xenix tends to look that bad too; probably it's written by the same 9 year old kids.) Of course as the code ports around it mostly gets cleaner (as it loses characters from the comments while traveling over lossy serial lines) but it almost never compares with code written on Unix systems by people who are paid well to do it well -- like most of us. It's taken about 6 months to get a version of "arc" (written in C for msdos) to run semi-reliably on machines with different byte order, different order of execution, or different word sizes than the 8088. > "... 95% of all C programmers couldn't give you a good > explanation of the term lvalue..." > "... 99% of all professional C programmers have no idea > what typedef is all about, couldn't care less and probably > won't ever need it." > "... 99% of all professional C programmers have no idea > what the comma operator is all about, couldn't care less and > probably won't ever need it." > "... a C programmer never needs to know what a byte is..." If you leave the word "professional" out of the above, I would agree. It gets demonstrated about once a month in this newsgroup just how little lvalues are understood. I don't think I've ever coded a typedef definition -- and just because you can write caddr_t foo; doesn't mean you know how or why it works. Most of the uses people put comma to are confusing to read, like the "old standard" for-loop where you have to squint the commas from the semicolons. It's absolutely true that a good C programmer doesn't ever need to know about bytes. I might (at 3AM) go so far as to say that a place in a C program that "knows" about bytes is a portability bug waiting to happen. Ask a PDP-10 C hacker, on a machine where copying all the bytes doesn't necessarily copy all the bits. One of the posters on this review said "A good understanding of bytes is essential in writing portable C programs" or words to that effect. I'll admit I understand bytes, but I think this makes me a *worse* C programmer, because I make unportable assumptions based on my understanding of how my local machine actually implements C constructs. > "... Leave the comma operator altogether. An intro book is no > place for obscure and unmaintainable tricks..." While most people will never use some parts of the language, a textbook should document it all, in case you run across it in other peoples' code. > "... Switch/case could be classified as rarely used and should be > kept till later. > "... very few C programmers know much about sizeof..." > "... Pointers to functions ... few C programmers understand > them or would ever need them..." These are off base, though it was news to me that sizeof worked on arbitrary expressions. -- John Gilmore {sun,ptsfa,lll-crg,ihnp4}!hoptoad!gnu gnu@ingres.berkeley.edu /* No comment */
msb@sq.UUCP (01/16/87)
One more message that couldn't be mailed to "Peter Steele - Acadia" (PLEASE get your software fixed!)... All right, speaking as a professional C programmer, here are *my* opinions: > "... 95% of all C programmers couldn't give you a good > explanation of the term lvalue..." True. And what's more, of the other 5%, they probably split between two different explanations of what it means. Either (a) something that you can put on the left side of "=", or (b) an expression that designates a genuine object [including, for instance, an array name, but not something like ++p]. > "... Switch/case could be classified as rarely used and should be > kept till later." Garbage. > "... very few C programmers know much about sizeof..." Not "very few", but "some". Your book can help educate them. sizeof *should* be used in conjunction with malloc and fread, for instance. > "... 99% of all professional C programmers have no idea > what typedef is all about, couldn't care less and probably > won't ever need it." Well, maybe 85%. I rarely use it myself; I think it's only useful in connection with library packages where you want to conceal what type something is, and in connection with portability definitions such as size_t (the type of the result of sizeof). > "... 99% of all professional C programmers have no idea > what the comma operator is all about, Garbage. > couldn't care less and > probably won't ever need it." > "... Leave the comma operator altogether. An intro book is no > place for obscure and unmaintainable tricks..." I tend to agree with this part, to a limited extent. > "... Pointers to functions ... few C programmers understand > them or would ever need them..." Possibly true. It's certainly one of the more "advanced" parts of the language. > "... a C programmer never needs to know what a byte is..." Well, it's what the value returned from sizeof is measured in. A few comments of my own. I hope you guys are following the ANSI people and their drafts of a C standard. It would be a good idea to include in an appendix a summary of the innovations in the latest draft, identifying it as a draft; for instance, the const modifier and the signed char type. If the book is really supposed to be introductory, I hope you will include an appendix sketching briefly the things you didn't cover (pointers to functions could well go there, I think, and maybe the comma operator). I've seen one introductory C book that didn't mention the existence of "short" and "long", thus guaranteeing that their readers' programs won't be portable if their ints ever go over 32767... I think "long" should be introduced right alongside "int", but it would have helped if they'd at least put it in an appendix. Mark Brader, utzoo!sq!msb #define MSB(type) (~(((unsigned type)-1)>>1))
gwyn@brl-smoke.ARPA (Doug Gwyn ) (01/17/87)
In article <7521@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >The comma operator ... is convenient from time >to time, but its real importance comes in very specialized situations. Mostly in the definition of a macro that needs to accomplish a side-effect as well as return a computed value, e.g.: #define next(p) (count++, *p++)
ben@catnip.UUCP (01/18/87)
In article <1667@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes: >The reviewer has probably been reading C code written by graduates from >the 8088 assembler school of engineering. I hope I'm not the only one >who noticed the really *low* quality of public domain software written >in C on (non-Unix) micros. (Code first written on Xenix tends to look >that bad too; probably it's written by the same 9 year old kids.) John, this if both an untrue and absurd statement. People who have Intel 80x86 based Unix micros (such as Xenix and Microport) are actually *more* aware than you 68000 types about portability concerns. We are the ones who get bitten when someone assumes sizeof(int)=sizeof(long), address spaces are huge and contiguous, or make other false assumptions. >It's taken about 6 months to get a version of "arc" (written in C for >msdos) to run semi-reliably on machines with different byte order, >different order of execution, or different word sizes than the 8088. As a person who ported the recently posted Unix arc sources to Xenix, let me assure you that many of the portability problems were introduced by the Unix guru who ported arc to Unix (on a 68000 based micro no less) * He was the one who broke the squeeze code by hard coding sizeof(int) as 16 bytes (sic) * He was the one who shifted a (possibly 16 bit) integer left 24 bits * He was the one who ported the coreleft() test (to prevent arc from running out of memory) by removing it, and returning "always enough core" +++ +++ The bottom line is that arc, written for the 80x86 processor, +++ would not run correctly on the 80x86 after it was supposedly +++ portably converted to work on a 68000. You couldn't have picked +++ a worse example to support your claim. +++ Look, you may not like the Intel architecture. (I sure don't) But classifying programmers who program on these machines as '9 year old kids' is assinine. Perhaps people who program on Suns and Apollos write better code (because only professionals can afford these machines), but there is just as much bad C code written for the Amiga, Atari and Mac as there is for the IBM PC and AT families. -- Ben Broder {ihnp4,decvax} !hjuxa!catnip!ben {houxm,clyde}/
bzs@bu-cs.BU.EDU (Barry Shein) (01/18/87)
This reviewer is a loser, demand his/her/its credentials. Someone thought the reviewer must be a hopeless academic, I find it hard to believe any academic would disparage use of terms like 'lvalue', more likely the opposite, also the obsession with "very few professional programmers know about..." sounds more like an industry person trying to pontificate on the state of art then someone who *teaches* people (such people don't usually criticize based upon the premise that some knowledge is *bad* for the student.) I reviewed a C book about a year ago for A-W which was a total loser, but boy-o-boy did my crits not sound anything like that (more like "it is obvious the author has never written a C program and is faking it from some rudimentary knowledge of some other, undisclosed, programming language...".) I mean, the examples couldn't work and the code often used inappropriate control and data structure for the problem at hand. Not to mention that his explanations were wrong... If it's A-W you might ask them to ask me to provide another opinion, but no promises, I teach C here at BU and take it all rather seriously. Ooops, maybe now I'll hear my flames on this list :-) -Barry Shein, Boston University
mwm@eris.BERKELEY.EDU (Mike Meyer) (01/18/87)
In article <3548@bu-cs.BU.EDU> bzs@bu-cs.BU.EDU (Barry Shein) writes: >This reviewer is a loser, demand his/her/its credentials. True. >Someone thought the reviewer must be a hopeless academic, I find it >hard to believe any academic would disparage use of terms like >'lvalue', more likely the opposite, also the obsession with "very few >professional programmers know about..." sounds more like an industry >person trying to pontificate on the state of art then someone who >*teaches* people (such people don't usually criticize based upon the >premise that some knowledge is *bad* for the student.) What I thought interesting about the "9x% of C programmers" statements was that, if true, they make a good case for discussing them in a C book. Actually, I think someone needs to write a paper on teaching C; "Teaching the lingering illness", or some such. <mike
lmiller@venera.isi.edu (Larry Miller) (01/19/87)
Alex Quilici and I have written a C book for John Wiley that came out last year. We had several very good (i.e., helpful) reviews from many different people. I can only conjecture that there are at least two explanations for your reviewer's mistaken notions about what C programmers do/need/want: 1) He's written his own book and is trying to reduce the quality of yours. 2) He's a nut case and should be ignored. Assume, however, for the moment, that he's correct. What can be done to cover these important topics (ptrs to functions, comma operator, etc.), and yet not have them seem overly fussy, pedantic? That's what makes a good book, and a good writer. For some good examples, see Lawrence Miller and Alex Quilici, "Programming in C," John Wiley, 1986! Larry (I'd like to wish you good luck, but not too much!!)
franka@mmintl.UUCP (Frank Adams) (01/20/87)
In article <1462@blia.BLI.COM> forrest@blia.UUCP writes: >I do freelance technical reviewing for several publishers and >have some feel for what goes into such reviews. I think the major >reason for your surprise is because the reviewer that examined >your book (not me, by the way) may have been including >people who program in C on micros in his comments. These people >don't always have the same level of experience as Unix (or VMS) >hackers. Beware of overgeneralization! We have quite a few people who program in C on micros, and the comments made by the reviewer certainly don't apply to them. Now, if he had said "amateur" instead of "professional", *some* of those statements might have been on target. Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Multimate International 52 Oakland Ave North E. Hartford, CT 06108
btb@ncoast.UUCP (01/20/87)
I agree with Clayton, the guys who wrote that book have obviously never read K&R, or written C programs... my primary daily work is not in C, but I know about all of the things that Clayton responded about, and in fact, as a "raised on Pascal" programmer, I have found typedef, and sizeof to be wonderful features of C... I also have found great uses for the comma operator.. it often allows you to write a for loop without any body at all. By the way, my daily work is in Ratfor and Fortran, and SORRY about posting this, but reply doesn't work at our site. -- Brad Banko ...!decvax!cwruecmp!ncoast!btb Cleveland, Ohio "The only thing we have to fear on this planet is man." -- Carl Jung, 1875-1961
kc@rna.UUCP (Kaare Christian) (01/20/87)
I agree with all of your respondents that the given comments on C are pretty far out of line, especially given your intent to write a non-intro type C book. Although I disagree with statements such as ``case is rarely used'' you might find it useful to try to understand what aspect of your manuscript led the reviewer to make such outlandish statements. Although most would disagree with the reviewer's specific comments, they may be his/her best effort at expressing valid objections. For example your presentation of the comma oprator, which is often used obscurely, may have lacked inadequate warnings about order of evaluation difficulties. Or your discussion of typedef may have lacked motivation. The reviewer just *might* be incoherently giving you some good advice. In my experience many reviewers (in many fields) have trouble explaining what they don't like about something. Only the very best reviewers are able to explain their objections adequately. Kaare Christian cmcl2!rna!kc (On the other hand, the reviewer may be completely incompetent.)
guy%gorodish@Sun.COM (Guy Harris) (01/20/87)
> People who have Intel 80x86 based Unix micros (such as Xenix and Microport) > are actually *more* aware than you 68000 types about portability concerns. > We are the ones who get bitten when someone assumes sizeof(int)=sizeof(long), Wrongo. Some 68K implementations have 16-bit "int"s and 32-bit pointers and "long"s; those of us who have worked on such implementations are quite aware of this. > >It's taken about 6 months to get a version of "arc" (written in C for > >msdos) to run semi-reliably on machines with different byte order, > >different order of execution, or different word sizes than the 8088. > > As a person who ported the recently posted Unix arc sources to Xenix, > let me assure you that many of the portability problems were introduced > by the Unix guru who ported arc to Unix (on a 68000 based micro no less) It seems doubtful that problems in porting "arc" to a non-808* machine were caused by its port to a 68K-based machine! My own favorite "worst architecture/C implementation" for encouraging non-portable code is VAX UNIX's, but so what? There is a distressing tendency amongst C programmers on *all* implementations to write non-portable code when with little or no extra effort, and little or no cost in efficiency, they could write the same code portably. Trying to pin the blame on one particular machine or on one particular C implementation on that machine is pointless.
grr@cbmvax.cbm.UUCP (George Robbins) (01/23/87)
In article <2313@brl-adm.ARPA> Peter@adm.UUCP writes: >I am currently finishing up a new text book on C with a colleague >of mine... Well, I found about a million of these piled up in comp.lang.c and tried to resist - but - it's interesting. Your reviewer was obviously hopeless or in a foul and snappy mood but he indirectly does point at a few of the lingering problems with c...these are things that come up over and over again and send learners to the (hopefully) guru. >"... 95% of all C programmers couldn't give you a good >explanation of the term lvalue..." Well, maybe 30% couldn't get every one of the details right and perhaps 5% are terminally confused (check this newsgroup). >"... Switch/case could be classified as rarely used and should be >kept till later. BS here... >"... very few C programmers know much about sizeof..." Well everyone knows sizeof object, but sizeof pointers, expressions arrays, external items, parameters and whatnot needs to be explained or warned about... >"... 99% of all professional C programmers have no idea >what typedef is all about, couldn't care less and probably >won't ever need it." Well, many of the C texts, K&R included put more stress on #define and leave one wondering why you have both typedef and define. Discussion of typedef and examples of where it pays off are needed. >"... 99% of all professional C programmers have no idea >what the comma operator is all about, couldn't care less and >probably won't ever need it." >"... Leave the comma operator altogether. An intro book is no >place for obscure and unmaintainable tricks..." More BS, but the comma would seem to have bizarre semantics to anyone having just escaped pascal. Discussion should dissuade it's use except where it actually reduces confusion. >"... Pointers to functions ... few C programmers understand >them or would ever need them..." Clear discussion on how to declare pointers to functions and other complex types is needed. K&R tries, but give someone a broken compiler and let them try to work it out from the book! This is the spot to hammer typedef home again... >"... a C programmer never needs to know what a byte is..." Most programmers have picked this up by the time the try to learn C, so avoid the dumb analogy definitions and maybe discuss the relations between the char type and a byte, and why 8-bits isn't automatic... -- George Robbins - now working for, uucp: {ihnp4|seismo|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@seismo.css.GOV Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
jon@campari.UUCP (Jonathan Gingerich) (01/24/87)
While it is amusing to find the lang.c community asserting their thorough knowledge of the 'typedef' command at the same time there is evident confusion about the semantics of '|' and '||', it is annoying to see the poor referee of Peter's book get so unanimously trashed. There is much to object to in the replies, but the three most important points are the following: 1) It is very hard to judge the referees comments out of context. For instance when he states "...Switch/case could be classified as rarely used and should be kept for later" there is no reason not to believe that he is commenting on the relative placement of the switch/case discussion within the book. Nor can I tell if his comments about 'lvalues' are intended to caution the authors about making unwarranted assumptions about their reader's knowledge of the term or are suggesting the concept has little value, if either. 2) Most of his critics have misread his comments to set up straw men to attack. In the switch/case statement he merely says it "could be classified" as a rare construction, yet many seem to think he is denigrating the construction itself. Similarly, since the typedefs and the comma operator are demonstratably unnecessary, his opinions opinions on industry knowledge of these have nothing to do with their usefulness. 3) Finally, with irrasibility and rhetorical excess given its due, I think that what he says may be essentially correct. Simply because he has a dim view of the general level of C knowledge, does not mean he approves of this. I do find Peter's statement "It is not a intro text, it assumes the reader has finished a course in Pascal" somewhat tautological. My experience with students with one Pascal course under their belt does not make me sanguine about their abilities to absorb the whole of C. I am curious how Peter handles the comma operator. In my view there are three way to use it: badly, not at all, or well (and therefore rarely). Given that you are dealing with beginners, you must either devote a lot of time explaining how to use a rarely used construction properly, time which is better spent elsewhere, or provide only the briefest description to baffle all but those sophisticated enough to make proper use of it anyway. In any event, none of the referee's quotes would make me dismiss him out of hand. Indeed, I would read his comments carefully, he may be Peter's most valuable critic. I am not convinced that the lang.c community has the proper outlook to understand a beginners problems anyway. Look how much trouble we have explaining anything to each other! Jon. Gingerich