[comp.lang.c] Comments on new Kelley and Pohl /A Book on C/, other C teaching stuff

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