cs300@kuhub.cc.ukans.edu (07/21/90)
I'm teaching my first course in programming (I'd taught the survey course in CS previously), and am wondering what other people are using for the language they teach. I am forced by the curriculum to teach Pascal and I seriously question the wisdom behind teaching this language as the first one. Some of my reasons: The main technique to learn is abstract data types and modularity. Pascal adds all kinds of syntactic overhead to the structuring of data (e.g. "." vs "[]" for essentially the same thing: compound data) Pascal forces everything to be declared globally if it is to retain its value (i.e., there is no private data) Pascal punishes one for recursion (unless tail recursion is implemented) Procedures and functions are not first class data items and hence only a small subset of programming techniques is learned. Polymorphism is only difficultly achieved to a partial degree. Now, granted, some of these topics aren't always suitable for a first course, but the teaching of Pascal means that in order to learn them, one has to drop pascal (and all the bad habits its taught) and pick up a reasonable language. What's reasonable? If forced I'd teach Ada or C, but I prefer scheme(lisp). I'd like to think that I'm preparing my students for more that just FORTRAN and COBOL careers (or at least giving them the option to not choose those careers). Does anybody have any supporting or competing experience? I'm considering lobbying for an experimental course using scheme. Thanks, David (my opinions? you just got them).
mmh@cs.qmw.ac.uk (Matthew Huntbach) (07/25/90)
In article <24994.26a7079d@kuhub.cc.ukans.edu> cs300@kuhub.cc.ukans.edu writes: >Some of my reasons: >The main technique to learn is abstract data types and modularity. >Pascal adds all kinds of syntactic overhead to the structuring of >data (e.g. "." vs "[]" for essentially the same thing: compound data) I think the distinction between arrays - which are indexed - and records - which are not - is an important one. Of course, you should encourage the use of syntactic structures ONLY within procedures and functions which implement the abstract data types. In this way, the language syntax becomes a minor detail anyway. >Pascal forces everything to be declared globally if it is to retain its >value (i.e., there is no private data) I think this is acceptable for a first programming course. Introducing private data at this stage is only overloading the students. They will only get to see the benefit of private data as a result of experience, so it is better introduced in the second programming course. >Pascal punishes one for recursion (unless tail recursion is implemented) At the first programming course stage you shouldn't be worrying too much about efficiency. Students are unlikely to be writing programs where the inefficiency of Pascal's recursion implementation notices. >Procedures and functions are not first class data items and hence only >a small subset of programming techniques is learned. The use of higher-order functions often strikes me as a dirty programming trick, akin to the use of gotos. I don't think I have ever had to use it in ten years of writing programs. I have seen too many "clever" programs which make unnecessary use of procedures and functions as first class data items. I think it is best not covered at the initial stage. >Polymorphism is only difficultly achieved to a partial degree. Again, while polymorphism has benefits, at the initial stage there are positive benefits in NOT using it. Students ought to be thoroughly aware that a "list of X" is not of the same type as a "list of Y". > >Now, granted, some of these topics aren't always suitable for a first course, >but the teaching of Pascal means that in order to learn them, one has to drop >pascal (and all the bad habits its taught) and pick up a reasonable language. Any CS student worthy of the name ought to have no difficulty in switching languages. I don't think Pascal is perfect, but it's a reasonable compromise between various conflicting requirements. The important thing is to stress that it is being used as a teaching tool - making sure that students are aware you are teaching the principles of good programming, not "coding in Pascal". My main concern about the language is that many students coming to first programming courses already have a lot of experience with computers in high schools or as hobbyists. It is too easy to carry on bad programming techniques into Pascal. So I agree it may be good to shock them by introducing a completely different sort of language, either functional or logic. Matthew Huntbach
kanamori@Neon.Stanford.EDU (Atsushi Kanamori) (07/26/90)
In article <2560@sequent.cs.qmw.ac.uk> you write: >In article <24994.26a7079d@kuhub.cc.ukans.edu> cs300@kuhub.cc.ukans.edu writes: >>Some of my reasons: >>The main technique to learn is abstract data types and modularity. >>Pascal adds all kinds of syntactic overhead to the structuring of >>data (e.g. "." vs "[]" for essentially the same thing: compound data) >I think the distinction between arrays - which are indexed - >and records - which are not - is an important one. >Of course, you should encourage the use of syntactic structures >ONLY within procedures and functions which implement the >abstract data types. In this way, the language syntax becomes a >minor detail anyway. Agreed. Syntax is a minor issue. > >>Pascal forces everything to be declared globally if it is to retain its >>value (i.e., there is no private data) >I think this is acceptable for a first programming course. >Introducing private data at this stage is only overloading the >students. They will only get to see the benefit of private data >as a result of experience, so it is better introduced in the >second programming course. > Disagree. Whether or not abstraction can be left for a second course is arguable. But Pascal is openly hostile to modern abstraction methods. 1. No way to hide type definitions that are supposed to be private to a module. In fact, no way to hide definitions at all: so defining a module has the side effect of creating all kinds of unwanted global bindings. 2. Const, type and var declarations separated for the compiler's convenience, making it impossible to put related stuff together. How can you call it a module when it doesn't even look like a module? Most commercial Pascal compilers fix these but those languages aren't Pascal: they're C or Modula 2 with a Pascal-like syntax. Why not start off with a language that does this right instead of using Pascal for one course and then forcing students to unlearn it? >>Pascal punishes one for recursion (unless tail recursion is implemented) >At the first programming course stage you shouldn't be worrying >too much about efficiency. Students are unlikely to be writing >programs where the inefficiency of Pascal's recursion >implementation notices. As a recursion fanatic, I grudgingly agree that for a first course, students are unlikely to be solving problems for which recursion is appropriate. > >>Procedures and functions are not first class data items and hence only >>a small subset of programming techniques is learned. >The use of higher-order functions often strikes me as a dirty >programming trick, akin to the use of gotos. I don't think I >have ever had to use it in ten years of writing programs. I >have seen too many "clever" programs which make unnecessary use >of procedures and functions as first class data items. I >think it is best not covered at the initial stage. Wrong! First class procedures not only simplify a programming language by getting rid of the artificial distinction between variables and functions, but they are the only natural solution for many problems. Try writing a general integration routine, or a sorting routine that can use any ordering relation without higher order functions. The trick is to think of a function as a mathematical mapping, rather than place to branch to: then the notion of passing functions around becomes no more mysterious than passing large tables of input-output pairs around. > >>Polymorphism is only difficultly achieved to a partial degree. >Again, while polymorphism has benefits, at the initial stage >there are positive benefits in NOT using it. Students ought to >be thoroughly aware that a "list of X" is not of the same type >as a "list of Y". I disagree: often, a piece of code wants to think about general relationships between objects rather than the specific representations of the objects themselves. To take the sorting example again, why should the code for sorting care what X is if it can be abstracted away in the ordering relation passed to it as a parameter? Similarly, it's stupid to have to type "write-integer" to print integers, "write-string" to print strings and "write-foo" to write foos. Pascal gets around this by hypocracy: it violates its own type rules when it comes to primitive procedures like writeln. Message from Wirth: "I can do it but you can't. Nyaa nyaa." It took me a long time to shake off Pascal's "TYPES WILL BE DISJOINT!!!" dogma and embrace the more natural type hierarchies of object-oriented languages. Why not teach the right way to start with? > >I don't think Pascal is perfect, but it's a reasonable >compromise between various conflicting requirements. The >important thing is to stress that it is being used as a >teaching tool - making sure that students are aware you are >teaching the principles of good programming, not "coding in >Pascal". Pascal may have been good 20 years ago but computer science has made much progress since then. It is an antiquated and inadequate language and we should be looking for better ones. Re: Scheme as a first language, I'm a declared Scheme fanatic. I do have a couple of serious bitches though: 1. No way to statically declare the types of variables when I want to. How often have you looked at someone else's code: (define (foobar set1 mapping2 graph3) ...) and wondered specifically, what kind of objects foobar wants? 2. No sensible way to create variables and data private to a file. (define x #f) (define y #f) (let () ... lots of private stuff here ... (set! x (lambda...)) (set! y (lambda...))) is *not* an aesthetic solution. Nor is there any portable way to write a macro that does this, at least I haven't come up with one. Just my $.02.