Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rochester!ritcv!cci632!rb From: rb@cci632.UUCP (Rex Ballard) Newsgroups: comp.lang.misc,comp.edu Subject: Re: How to teach computers Message-ID: <920@cci632.UUCP> Date: Wed, 4-Feb-87 20:45:00 EST Article-I.D.: cci632.920 Posted: Wed Feb 4 20:45:00 1987 Date-Received: Sat, 7-Feb-87 08:40:17 EST References: <2980@gitpyr.gatech.EDU> Reply-To: rb@ccird2.UUCP (Rex B) Organization: CCI, Communications Systems Division, Rochester, NY Lines: 62 Summary: Get a teachable computer. Xref: mnetor comp.lang.misc:236 comp.edu:90 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.