Comments on new Kelley and Pohl /A Book on C/, other C teaching stuff

[Rich Walters]

In article <3087 at bingvaxu.cc.binghamton.edu> cjoslyn at 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

-------------------------------------------------------------------------------