Do NOT teach programming in abstract terms. Was: Can Novices Jump Directly in C? (Books)

[Dan Barrett]

In article <s64421.666449403 at zeus> s64421 at zeus.usq.EDU.AU (house ron) writes:
>This is my main point, IT IS VERY MUCH HARDER TO START WITH THE ABSTRACT AND
>MOVE TO THE CONCRETE THAN TO START WITH THE CONCRETE AND MOVE TO THE
>ABSTRACT.

	I assume you realize this is your opinion (not rigid fact), as these
kinds of educational issues are still not fully understood.  I'd say it
varies greatly with the student, the instructor, and the topic.

>That is, teach by examples!  THEN show the principles behind them.

	Some students love this and benefit from it.  Some absolutely hate
it and are totally confused until you show the principles.  It varies.  But
this is one valid approach.

>I just love these nice simple [pointer] pictures!  I use them all the time
>while teaching programming.  BUT do you know that the majority of
>students DO NOT KNOW WHAT THE ARROWS MEAN??

	This is a very good point.  I make it a habit to "demystify" these
picture in my lectures by using example addresses (actual numbers) like
"18243".

	My first lecture in Introduction To Computer Programming teaches
students what addresses are in an amusing fashion.  From then on, I can talk
about them any time I want to move from abstract to concrete (for example,
variable parameter passing in Pascal "hiding" the addresses of the arguments
from the programmer).

	IMHO, it is a valuable learning experience to write a linked list
program in which you use a 2xN array to represent the list, rather than
pointers.  (Column 1 is data, column 2 is the "pointer" (index) of the next
element in the list.)  (You know, the FORTRAN way. :-))  It teaches a lot
about addressing.

>I have taught a lot of Pascal, and I have come to the conclusion
>that C is a better beginner's language, precisely because it is
>harder to obscure what's really going on.

	For those very reasons, I don't like C as a beginner's language.  A
beginner has PLENTY of information to learn without having to deal with all
of C's subtleties right away.  Even simple C programs can have very
hard-to-find bugs.

	But I don't like Pascal as a first language either.  This is a
religious issue, so I won't say any more about it.

>I have been forced to the view that
>the average Pascal student learns to program by PATTERN MATCHING.

	Perhaps this phenomenon is not as widespread as you think.  I'm 
sure it depends on the quality of the instructor, the students, and the
homework assignments.  (I am NOT implying that you are a bad instructor.)

>That is, given a problem, write a solution which resembles a solution
>to a similar problem seen before, without any understanding of what
>is actually going on.  Then tinker with it until it works.

	Homework assignments can be designed to avoid this and test
conceptual knowledge.  It takes work, but can be done.  I speak from
experience.  (Side note:  these "pattern-matching" students don't do well in
my classes.)

	Summary:  I think people are going to flame you for the subject of
your posting ("Do NOT teach programming in abstract terms") because different
people have different opinions on the subject.  But, in fact, your article
itself was not truly anti-abstraction.  Instead, you seem to be arguing NOT
to OMIT the "concrete stuff".  This is a good point.

	IMHO, both abstraction and the "concrete stuff" are important to a
good understanding of programming.  If you don't teach abstraction at all,
some programming knowledge doesn't transfer well when you move to languages
with VERY different syntaxes and coding philosophies.  (Example:  C vs.
Prolog.)  In addition, abstraction can help your code to be more portable
and maintainable.  (Examples on request.)

	But teaching only abstraction can obscure some real issues.  In
this, I agree with you.

                                                        Dan

 //////////////////////////////////////\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
| Dan Barrett, Department of Computer Science      Johns Hopkins University |
| INTERNET:   barrett at cs.jhu.edu           |                                |
| COMPUSERVE: >internet:barrett at cs.jhu.edu | UUCP:   barrett at jhunix.UUCP    |
 \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\/////////////////////////////////////