Xref: utzoo comp.edu:2240 comp.lang.pascal:1783
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!tank!eecae!cps3xx!rang
From: rang@cpsin3.cps.msu.edu (Anton Rang)
Newsgroups: comp.edu,comp.lang.pascal
Subject: Re: CS-1
Message-ID: <2835@cps3xx.UUCP>
Date: 4 May 89 19:32:32 GMT
References: <2130@iitmax.IIT.EDU> <2394@brahma.cs.hw.ac.uk> <2680@puff.cs.wisc.edu>
Sender: usenet@cps3xx.UUCP
Reply-To: rang@cpswh.cps.msu.edu (Anton Rang)
Organization: Michigan State University, Computer Science Dept.
Lines: 64
In-reply-to: brian@cat28.CS.WISC.EDU's message of 4 May 89 17:16:49 GMT

In article <2680@puff.cs.wisc.edu> brian@cat28.CS.WISC.EDU (Brian Miller) writes:

   In article <2394@brahma.cs.hw.ac.uk> nick@cs.hw.ac.uk (Nick Taylor) writes:
   >In article <2130@iitmax.IIT.EDU> thssccb@iitmax.IIT.EDU (catherine c bareiss) writes:
   >>I am designing a beginning programming course.
   >>
   >>The structure is to be as follows:
   >>       One day a week, a lecture on a topic (using psuedo code).
   >                                              ^^^^^^^^^^^^^^^^^
   >
   >Is this a good idea? I know it is becoming more and more common to do this

   I agree.  Pseudo-code is a waste of time.  Teach the language and its
   principles (sp?).

I disagree, at least in part; perhaps my understanding of pseudo-code is
different from yours.  Teaching a *flexible* method of pseudo-coding is
basically equivalent to teaching top-down design principles.
  Now, I've seen classes which put a particular style of pseudo-code on a
pedestal (the intro to BASIC course here, for one); that seems a little
ridiculous to me.  (Their idea of pseudo-code is making up new keywords for
BASIC statements...well, almost.)
  Pseudo-code should be a way to design algorithms and programs without having
to worry about the syntactic sugar or limitations of a particular language.
For instance, consider this pseudo-code for a merge sort:

	Merge sort routine (one parameter, some data to sort).
	  1. If there is only one item to sort, just return (already sorted).
	  2. Split the data into two sets.
	  3. Sort each set, using the merge sort routine recursively.
	  4. Join the two sets together.

  This is my conception of what pseudo-code *should* be like.  This can be
treated like an outline, with more detailed instructions added for each part
(i.e. 4a, 4b, etc. detailing the final join operation).  More and more detail
can be added, perhaps including information about the data structures chosen,
until it is detailed enough to easily turn into code:

	Merge sort routine (one parameter, a linked list).
	  1. If there is only one item to sort, just return (already sorted).
	    a. Check if the next-item pointer of the list's head is nil.
	    b. Just return if it is; if not, go on.
	  2. Split the data into two sets.
	    a. Set up two empty temporary lists.
	    b. Go through the input, one item at a time.
	      (i) Add it to either list (alternate between them).
	...

  Again, flexible pseudo-code is good--it prevents the student from having to
worry about details like "how do I test if there is only one item?" or "how to
I find a value in a record when I have a pointer to it?" until they actually
write the routine.  Now, what passes for pseudo-code in many textbooks is much
too strict for this; I think it constrains creativity (though no more than
forcing students to implement an algorithm directly in some language).
  Just my thoughts...

		Anton

+---------------------------+------------------------+-------------------+
| Anton Rang (grad student) | "VMS Forever!"         | VOTE on	         |
| Michigan State University | rang@cpswh.cps.msu.edu | rec.music.newage! |
+---------------------------+------------------------+-------------------+
| Send votes for/against rec.music.newage to "rang@cpswh.cps.msu.edu".   |
+---------------------------+------------------------+-------------------+