Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!amdcad!ames!umd5!purdue!i.cc.purdue.edu!j.cc.purdue.edu!k.cc.purdue.edu!l.cc.purdue.edu!cik From: cik@l.cc.purdue.edu (Herman Rubin) Newsgroups: comp.lang.misc Subject: Re: Languages and learning (was: Philosophy of C) Message-ID: <666@l.cc.purdue.edu> Date: 24 Jan 88 12:49:09 GMT References: <11348@brl-adm.ARPA> <3473@ihlpf.ATT.COM> <3487@ihlpf.ATT.COM> Organization: Purdue University Statistics Department Lines: 84 Summary: Start with the concepts, not the manipulations 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" 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