lacey@batcomputer.tn.cornell.edu (John Lacey) (08/10/89)
On Aug 9, 3:41pm, in comp.lang.misc, Tapani Tarvainen wrote: } Subject: Re: Which language to teach first? } } In Jyvaskyla University Pascal is taught as the first language. } The most important reason (which disqualifies Ada in particular) } is the availability of cheap and easy-to-use compilers for PCs. } I suspect this is the decisive factor in quite a few places. And don't forget that languages with cheap and easy-to-use compilers will tend to be simple and easy-to-use languages. } I can't, however, resist the temptation to quote Edsger Dijkstra here He is _very_ quotable, isn't he? :-) } [describing his idea of an introductory programming course } in the 1988 SIGCSE Award Lecture (titled "On the cruelty of really } teaching computer science"!)]: } } "... we see to it that the programming language in question has _not_ } been implemented on campus so that students are protected from the } temptation to test their programs." Did you notice at that same sesssion (1989 SIGCSE), that a colleague of his from the Univ. of Texas at Austin spoke about using CASE tools in the introductory courses. I couldn't help but feel that they must have a very confused group of students down there. :-) Also, I am sure that I could find a few of his students willing to pay me to write a simple interpreter for whatever language he devises :-) :-) Seriously, I feel that Prof. Dijkstra has a point. There is a tendency to experiment with one's programs, to rearrange things a little and see if that works, rather than to try work out what the problem is, and what program should be written to solve it. He fears, quite justly, the replacement of thinking with experimentation. What he ignores, however, is the incredible feedback of interactive systems, and the ability to quickly learn from one's mistakes. Interactive languages and environments (such as Lisp, SmallTalk, and several PC implementations of Pascal, BASIC(!), and Modula-2) can be very powerful learning tools. In "The Little LISPer", Daniel Freidman and Matthias Felleisen call programming, and especially programming recursively, essentially an act of pattern recognition. In this context, you learn more by being in a pattern rich environment, even if many, if not most, of those patterns are incorrect. Yes, it is important to think carefully about what you are doing, and trial-and-error is not a good programming methodology (though as we know, it is a common one). But at the same time, we need experience in many different situations, and in dealing with misunderstanding and mistakes (errors of thinking and errors of action), both our own and those made by others. If I may, I would like to suggest a few ideas that might assist students in their learning. The trial-and-error method arises when students are given free rein to investigate their computing environment, such as in typical take-home lab assignments. As I said, this experience can be useful, but it must be tempered. I suggest doing so with two types of exercises. First, in-class exercises, without the use of a computer. These are to be graded with the intention that the students have produced working programs, and not simply rough algorithms. That is, they are to be graded as if they were take-home assignments. Second, on-the-fly lab exercises, in which students have access to computers during a normal class period. The reason for these exercises is to focus on interactive and visual programs---graphics and query systems, etc. And here, too, grading is not relaxed for the environment. I would be very interested in responses to these ideas. Also, I will present my ideas about languages in detail in another posting (the result of my inquiry about which language to teach first). Cheers, -- John Lacey lacey@tcgould.tn.cornell.edu cornell!batcomputer!lacey After August 16: jjlacey@owucomcn.bitnet If you have to, try mdl@sppy00.UUCP or maybe {...}!osu-cis!sppy00!mdl