🚀 go-pugleaf

In article <3487@ihlpf.ATT.COM>, nevin1@ihlpf.ATT.COM (00704A-Liber) writes:
> In article <11348@brl-adm.ARPA> dsill@NSWC-OAS.arpa (Dave Sill) writes:
> >In article <4186@eagle.ukc.ac.uk> "H.A.Shaw" <has@eagle.ukc.ac.UK> writes:

> >This is much too late.  Computer education should proceed from a
> >hardware overview to machine language to assembler language to low-
> >level compiled languages on up to high-level compiled languages.
> >Teaching BASIC/Pascal/FORTRAN/Forth/etc first is like teaching algebra
> >before arithmetic.

I would definitely teach algebraic _notation_ before arithmetic.  The
use of symbols for quantities is a great invention, comparable to the
invention of pronouns.  However, I would not teach any subject without
teaching the concepts first.  Unfortunately, I do not know of any subject
taught in this manner.  (It is very difficult for someone who has had a
statistical methods course to be able to grasp the assumptions involved
in a statistical situation.)  

> Yes, but arithmetic is usually first taught without logic and the axioms of
> arithmetic.  If you started your mathematics career with only the Successor
> function and the few other rules you need to define arithmetic, I don't think
> you would have gotten very far. 

Unfortunately, you are right; the arithmetic teachers cannot understand them.
What are you criticizing?  One should start with the notion of successor, i.e.,
the idea of _counting_.  Then addition is _continuing the count_ and multipli-
cation is repeated addition.  After this is done, a child can understand that
using addition and multiplication tables speed the process, not that they are
new processes.  If arithmetic were taught this way, using symbolic notation,
we would have people who understand it  Do not confuse requiring that all
statements are proved (completeness) with requiring that all statements are
correct (rigor).  Also, starting with successor does not prevent the later
use of the cardinal approach, or extending to rational numbers, negative
numbers, real numbers, complex numbers, etc.

> Analagously,
> try teaching someone how to write a exponentiation routine with a
> Turing machine (or another simplistic model of a computer).

That a Turing machine can do everything a computer can do does not make it
necessarily the only simple model of a computer, any more than the understand-
ing of arithmetic starting from counting precludes the use of place notation
and addition and multiplication tables.

> Unless you have a
> higher level concept of what things like lists, queues, and stacks are,
> programming in assembler is extremely tough.  There are no data structures in
> assembler, and this makes it tough to do any kind of non-trivial programming.
> HLLs are much better at learning the fundamentals of data structures and
> thinking abstractly.

I do not consider lists, queues, and stacks as any more abstract than overflow,
GOTO, and the hardware organization of items.  Data structures should be added
to the assembler; the HLL syntax, including weak typing, should be added.  
Macros of the form 
	X = Y + Z
and
	Q,R = M / N
should be added.  Start with what the hardware can do and proceed accordingly.

> One of the major habits is un-structured programming.  

I can give you examples where GOTOs are the simple thing to do, and the
"structured" alternatives are much more complex.  Structured programming
can block thinking of the efficient way to do things.
 
> Also, machine language allows self-modifying code, which is a no-no by today's
> standards.  

That you can cut yourself by using a knife does not mean knives should not be
used.  If self-modifying code is the thing to do, do it!

> Machine language is NOT the place to start learning about computers or to
> program them.  HLLs have too many advantages over machine languages.  

From the discussions I have seen, starting with machine languages _may_ be
more difficult.  However, I believe that for each person who has problems
starting with even the bad machines languages, dozens who start with the
HLLs will never be able to understand how to program anything that their
HLL does not support.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (ARPA or UUCP) or hrubin@purccvm.bitnet