🚀 go-pugleaf

In article <2980@gitpyr.gatech.EDU> scott@gitpyr.UUCP (Scott Holt) writes:
>
>	I once heard an idea from a professor of mine: teach them the
>theory first, save the programming till later. The more I think of this
>the better I think it is. 
>				- Scott Holt

I would agree.  I also agree with a subsequent poster that it is important
to get them involved with the machine as well.

I used to teach 8-18 year olds about computers.  Rather than jumping
immediately into a programming language, we had a "logo-like" interactive
system which taught the concepts of sequential instructions, stored programs,
variables, iterations, conditionals, procedures, and  funtions.  By teaching
them what I call "macro thinking", ie. breaking the problem down from the
top down then building the solution from the bottom up, it became a simple
matter to move them into even BASIC without them learning bad habits as
part of the language.  Several students made the transition from BASIC to
Pascal to even assembler or FORTH in a matter of a few weeks simply because
they knew how to express themselves in terms of macros.

I chose the "logo-like" language because it was relatively easy to learn,
interactive, and gave immediate feedback with reguard to the results of
a program.  They could see the pieces execute and put them together.  In
addition, graphics were well supported and made the course more interesting.
I wasn't wild about BASIC because it is possible to learn some very bad
habits with this language, but because it was interactive, and was preceeded
by the earlier background, students were less prone to commit them.  Again
graphics was also important.  We chose FORTH because it was again interactive,
and forced one to completely understand the problem since the solution HAD
to be built from the bottom up.  Even the Assembler was really a debugger
with a "save" capability.  In each case, graphics and sound routines were
used to improve the interaction and immediate feedback.

The key to these language choices was that it made the computer "teachable"
rather than "programmable".  There were few "magic functions", so the students
were able to understand how each piece worked.  In addition, they were able
to build on previous work without having to recompile everything.  It was
also possible to "unit test" each piece of code, and gradually test the
various levels of integration.

Many of my students had difficulty with Pascal because they not only had
to write each routine, but they also had to write the "unit test" calls
into their mainline routines.  Once they got past the semantics, and
learned the "workbench" however, they had little difficulty getting
working code in the relatively short time available (45 mins of class,
no lab work).

After working on and debugging "top down implementations" where the
aim was to start with the mainline and "fill in the stubs", and "discovering"
bugs in code that had never been executed before (for example code that
destroys the stack),  I am glad I taught "bottom up implementation".

One of the things I found especially interesting was the way the more
"artistic" (musicians, artists, writers) students began to do their
programming when they were allowed to try some "free style" assignments.
They would simply build the primatives and combine them in various creative
ways.  In these assignments, there was no "set problem" to be solved, just
a program that would do something interesting without breaking.
One of my students even came up with a commercially marketable product.

Rex B.