Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ucbvax!hplabs!hplabsz!taylor
From: taylor@hpdstma.hp.com (Dave Taylor)
Newsgroups: comp.edu
Subject: Cheating and learning
Message-ID: <2155@hplabsz.HPL.HP.COM>
Date: 28 Jul 88 18:26:42 GMT
Sender: taylor@hplabsz.HPL.HP.COM
Organization: Hewlett-Packard University Grants Program
Lines: 78

I think that a lot of interesting points have been raised so far in this
discussion, but I'd like to add a few of my own (not necessarily unique).

The basic question that this all revolves around, I think, is Why are
people taking the class?  For the most part, when I was in college (UCSD
for my undergrad work) I was in the class to learn as much as possible
about not only the subject matter but solution methodologies, debugging
techniques (something that is *never* taught), and ways to ensure that I
would be a success as a programmer were I to choose it as a profession.

By the numbers:

1. to learn the subject matter

   Learning is by doing, so the part of programming classes that
   I best remember is the homework assignments (which I always
   did as soon as they were assigned).  I always did my own work,
   but working in groups was educational too, leading to:

2. to develop the ability to communicate with my peers in a
   work/project situation, and to work with a group

   This is another skill that isn't really taught, but is
   instead thrust upon the students.  Why not classes on "how to
   work with people" and such instead of the typical fight for 
   control/lack of initiative/crummy partners cycles that go on?

3. to learn how to communicate my solutions to an impartial, but
   knowledgeable third party

   If the grader didn't like the way I programmed (which happened
   a couple of times) then I'd get poor grades on my assignments.
   If it didn't make sense, if it was confusing, if it wasn't well
   and thoughtfully commented, if ... well, it's another skill
   that serves well in life.

4. to learn how to solve problems

   This is probably one of the so-called metagoals of a college
   education - to learn how to approach a problem and dissect it,
   then solve it.  In programming, this sometimes required that you
   experiment with algorithms, and sometimes required that you
   learn how to use outside reference works:

   Part of problem solving is to solve problems that are raised
   by the particular implementation (eg. debugging).  That is, as
   mentioned above, sorely lacking in current CS coursework.

5. to learn how to use reference material

   I believe that there are certain classes of assignments that
   are best and most reasonably solved by consulting a reference
   work like Knuth and using it as the basis for your own
   implementation (properly cited, of course).  There are also
   others that are better left for the student to experiment
   with, however ("what algorithm works best in this situation"
   is a good experimentation example, and "what's the best way to
   implement this algorithm" is a good reference example).

Without totally belabouring the point, I think we can probably
agree that there are a number of problems that are best suited
for either learning by experimentation or learning by leveraging
off of other, standard reference works (by way of example, art
classes use paintings from other painters, music classes use
music from other composers, writing classes and other writers,
even hardware design classes and other designs (also known as
the Verezano Narrows Syndrome ;-)).   The class of problems
in the middle, that could be done either way, is probably 
best left to student initiative, with the grader encouraged to
rate them based on *initiative* and *thinking* demonstrated,
rather than whether it's the optimal solution or not...

[in real life we rarely have time to find and implement the
optimal solution; if it's "pretty good" then it's probably 
good enough to get on with the job...]

				Thoughts?

				   -- Dave Taylor