cjoslyn@bingvaxu.cc.binghamton.edu (Cliff Joslyn) (03/04/90)
A while back I asked this group for good refs to C textbooks. This semester I'm a new C teacher, and I'm reconsidering the text and my methods going into the summer semester. We rejected the old Kelly and Pohl's /A Book on C/ because it seemed really insufficient and incoherent. Eventually I settled on Kochan's /Programming in ANSI C/, which is OK, if a bit shallow on technical details, examples, and exercises. Now they've produced a second edition, which is significantly revised. It is much more in depth, with a lot of care to pedagogical devices and sufficient depth on important topics. I've also been referred to Tom Plum's /Learning to Program in C/. Is it ANSI? We need that. . . The other problem I've been struggling with all through this class is a bit of an *ordering* problem. Are there opinions on the right order to introduce subjects in? For example: arrays, structures, unions, then pointers, in order to talk about pointers to aggregate types of all kinds; or arrays and pointers together for the conceptual tightness, then what about structures and unions before or after? Control flow statements before or after functions? Defined constants and macros soon after functions in order to write good code soon, or deal with the whole preprocessor towards the end as an "advanced" feature? An overall question is whether to "preview" useful but perhaps potentially dangerous features which the student must accept on faith until dealt with sufficiently later on, or to rigorously introduce features in depth and in logical order. Examples: scanf() seems necessary early on, but I can't explain &num then or #include <stdio.h> in depth; using function return values before explanations of function declarations and prototypes; etc. This goes to the question of whether a first "tutorial chapter" with a preview is a good idea (K+R, Kelley and Pohl) or not (Kochan). Any help would be appreciated. . . -- O-------------------------------------------------------------------------> | Cliff Joslyn, Cybernetician at Large, cjoslyn@bingvaxu.cc.binghamton.edu | Systems Science, SUNY Binghamton, Box 1070, Binghamton NY 13901, USA V All the world is biscuit shaped. . .
raw@math.arizona.edu (Rich Walters) (03/04/90)
In article <3087@bingvaxu.cc.binghamton.edu> cjoslyn@bingvaxu.cc.binghamton.edu (Cliff Joslyn) writes: > > [some deleted stuff] > >The other problem I've been struggling with all through this class is a >bit of an *ordering* problem. Are there opinions on the right order to >introduce subjects in? For example: arrays, structures, unions, then >pointers, in order to talk about pointers to aggregate types of all >kinds; or arrays and pointers together for the conceptual tightness, >then what about structures and unions before or after? Control flow >statements before or after functions? Defined constants and macros soon >after functions in order to write good code soon, or deal with the whole >preprocessor towards the end as an "advanced" feature? > The answers, IMHO, depend on the experience of your students. Is this a beginners class? Are they required to know another language(ie Pascal) before entering this class? Other relevant questions: Is this a one,two or three semester course? Is the student expected to use this as a basis for other mor advanced courses? Is this a formal or informal course? From your phrasing it seems to a a formal lecture course. Is it a required course in a major/minor track or is it an elective? Assuming your students are complete novices, the following may be useful: control structures sub-programs (ie functions ,subroutines ) arrays structures unions (briefly) pointers special stuff (ie macros, defines, cpp goodies) This is covered here at the UofA (go wildcats) in a two semester CS sequence using Pascal and introducing/encouraging C in the second semester. >An overall question is whether to "preview" useful but perhaps >potentially dangerous features which the student must accept on faith >until dealt with sufficiently later on, or to rigorously introduce >features in depth and in logical order. Examples: scanf() seems >necessary early on, but I can't explain &num then or #include <stdio.h> >in depth; using function return values before explanations of function >declarations and prototypes; etc. This goes to the question of whether >a first "tutorial chapter" with a preview is a good idea (K+R, Kelley >and Pohl) or not (Kochan). Again, this depends on the knowledge of your students. If they are rank beginners, you all almost forced to introduce "potentially dangerous features" if they are to accomplish anything. Your example of scanf() is good. If you go into a lot of detail about pointers (include files,preprocessor) too early you may (IMHO _will_) confuse a good portion of your students and they will lose time attempting to grasp this concept while they could be profitably learning more basic concepts. You have succinctly covered most of the reasons why I think Pascal should be taught as a first language. The "dangerous features" and logical order problems just don't exist in Pascal. I suppose this boils down to 'Talk to your audience'. To reasonably answer your concerns, more information about your intended audience must be provided. ------------------------------------------------------------------------------- Keep on crunching those numbers -------------------------------------------------------------------------------
cjoslyn@bingvaxu.cc.binghamton.edu (Cliff Joslyn) (03/05/90)
In article <1486@amethyst.math.arizona.edu> raw@math.arizona.edu (Rich Walters) writes: >The answers, IMHO, depend on the experience of your students. Is this a >beginners class? Are they required to know another language(ie Pascal) before >entering this class? Yes, I should have been better at giving the context. These are adult undergraduates (second semester freshpeople) with a preliminary course in Pascal. My course is one semester only, required, and intended to get the language and good programming practices into their heads. Later in the program, they will use C for database and OS/compiler implimentation. >Assuming your students are complete novices, the following may be useful: > > control structures > sub-programs (ie functions ,subroutines ) > arrays > structures > unions (briefly) > pointers > special stuff (ie macros, defines, cpp goodies) This is basically what I'm doing, except I moved macros and defines before arrays (perhaps a mistake). What I really think is useful now is to combine arrays and pointers. There are advantages and disadvantages both ways, but it's real confusing when I say "don't pass arrays, they don't pass by value! Here in this call to printf( "%s\n", str ); I'm violating my own edict against passing arrays, but we have to." >Again, this depends on the knowledge of your students. If they are rank >beginners, you all almost forced to introduce "potentially dangerous features" >if they are to accomplish anything. Your example of scanf() is good. If you >go into a lot of detail about pointers (include files,preprocessor) too early >you may (IMHO _will_) confuse a good portion of your students and they will >lose time attempting to grasp this concept while they could be profitably >learning more basic concepts. Yes, this is just what I've found this semester. O-------------------------------------------------------------------------> | Cliff Joslyn, Cybernetician at Large, cjoslyn@bingvaxu.cc.binghamton.edu | Systems Science, SUNY Binghamton, Box 1070, Binghamton NY 13901, USA V All the world is biscuit shaped. . . -- O-------------------------------------------------------------------------> | Cliff Joslyn, Cybernetician at Large, cjoslyn@bingvaxu.cc.binghamton.edu | Systems Science, SUNY Binghamton, Box 1070, Binghamton NY 13901, USA V All the world is biscuit shaped. . .
jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) (03/05/90)
In article <3090@bingvaxu.cc.binghamton.edu> cjoslyn@bingvaxu.cc.binghamton.edu.cc.binghamton.edu (Cliff Joslyn) writes: >>If you >>go into a lot of detail about pointers (include files,preprocessor) too early >>you may (IMHO _will_) confuse a good portion of your students and they will >>lose time attempting to grasp this concept while they could be profitably >>learning more basic concepts. I am a student, not a teacher, but this gives me a great chance to observe which of my profs are the most effective... I would like to comment that I think the most effective teaching occurs when the material is covered in depth of detail, energetically, and in a logical sequence that does not require the student to figure out unexplained constructs. I also have been helped a lot by the "dissection" approach, where a code sample is explained construct-by-construct. I learned C by reading K&R and working the examples, (I bought it when it sold for $13.95) and from there reading other code, books, and writing stuff. Personally I have been very disappointed with most of the books on C, and still findk K&R to be the most valuable. -- John Dudeck "You want to read the code closely..." jdudeck@Polyslo.CalPoly.Edu -- C. Staley, in OS course, teaching ESL: 62013975 Tel: 805-545-9549 Tanenbaum's MINIX operating system.
reggie@dinsdale.nm.paradyne.com (George W. Leach) (03/05/90)
In article <25f1f465.347a@polyslo.CalPoly.EDU> jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) writes: >I would like to comment that I think the most effective teaching occurs when >the material is covered in depth of detail, energetically, and in a logical >sequence that does not require the student to figure out unexplained >constructs. I also have been helped a lot by the "dissection" approach, >where a code sample is explained construct-by-construct. I think we can all agree upon the above approach. >I learned C by reading K&R and working the examples, (I bought it when it >sold for $13.95) and from there reading other code, books, and writing >stuff. Personally I have been very disappointed with most of the books >on C, and still findk K&R to be the most valuable. I also learned from K&R, simply because it was the only thing available at the time! I still find it is the most useful book on C that I own. Although Harbison & Steele get a great deal of attention as well. I am using K&R for a course that I am teaching. The choice was not mine. I like using this book because the students will be able to use it long after the course is done with. However, it is difficult to overcome the problem of constructs being used in examples long before they are covered. For example, we are just starting on arrays and points. However, arrays are all over the book prior to the chapter that covers them. However, on the other hand, this forces me to come up with alternative examples that do *not* include constructs that have not been introduced thus far. I think this helps the students tremendously. I give them alternatives to what is in the book. George George W. Leach AT&T Paradyne (uunet|att)!pdn!reggie Mail stop LG-133 Phone: 1-813-530-2376 P.O. Box 2826 FAX: 1-813-530-8224 Largo, FL 34649-2826 USA