mgreen@cs.toronto.edu (Marc Green) (08/09/90)
I'm teaching a two term course in programming languages. I want to stress principles rather than specific languages. I'm finding it a difficult subject to teach. Last year, I ran through "features" (data structures, control structures, etc.) the first term and languages the second. It didn't seem to work well that way. I'm hoping to ge some suggestions from the more experienced on good ways to organize such a course. I'm also looking for suggestions on useful readings. Thanks. Marc Green Trent University
rwallace@vax1.tcd.ie (08/10/90)
In article <90Aug8.173401edt.7886@neat.cs.toronto.edu>, mgreen@cs.toronto.edu (Marc Green) writes: > I'm teaching a two term course in programming languages. I want to > stress principles rather than specific languages. I'm finding it a > difficult subject to teach. Last year, I ran through "features" (data > structures, control structures, etc.) the first term and languages the > second. It didn't seem to work well that way. > > I'm hoping to ge some suggestions from the more experienced on good > ways to organize such a course. I'm also looking for suggestions on > useful readings. Stressing principles is a nice idea but I've yet to meet anyone who learned any principles of computer science without first doing the practice. The point here is that perhaps you should concentrate on first teaching people a lot of different languages and then they'll be able to pick up the ideas. Say your students have learned a language like C which is suitable for software engineering. You could try giving them introductions to FORTRAN, COBOL, BASIC, Lisp, Forth, Algol etc. and hope they pick up some ideas of what programming languages are about. At the very least it'll teach them to appreciate the good qualities of whatever language they've been learning for mainstream programming :-). "To summarize the summary of the summary: people are a problem" Russell Wallace, Trinity College, Dublin rwallace@vax1.tcd.ie
jipping@smaug.cs.hope.edu (Mike Jipping) (08/14/90)
>> I'm teaching a two term course in programming languages. I want to >> stress principles rather than specific languages. I'm finding it a >> difficult subject to teach. Last year, I ran through "features" (data >> structures, control structures, etc.) the first term and languages the >> second. It didn't seem to work well that way. > The point here > is that perhaps you should concentrate on first teaching people a lot of > different languages and then they'll be able to pick up the ideas. Say your > students have learned a language like C which is suitable for software > engineering. You could try giving them introductions to FORTRAN, COBOL, BASIC, > Lisp, Forth, Algol etc. and hope they pick up some ideas of what programming > languages are about. At the very least it'll teach them to appreciate the good > qualities of whatever language they've been learning for mainstream programming > :-). But it won't teach them much else... That method will give them the mechanical ability to say "in this situation, I use C and in this situation I use Ada", but it won't give them the ability to intelligently CHOOSE a language which fill the application's need. For example, fully exploring concepts like data abstraction or static and dynamic identifier scope will teach knowledge that a tutorial approach never will. You can't "hope they pick up some ideas" and expect students to learn what the "hole in scope" problem is and how to avoid it. Learning CONCEPTS is the only way to adequately prepare a student for big world of languages. That isn't to say that "first doing practice" must be avoided. Examples, lab experiments, and programs programs programs can be given (and MUST be given in a good course) to illustrate both the point of the current concept and a particular way that a language implements a concept. I've taught a course in PL concepts for several years and a colleague and I have authored a 1990 book on PL concepts. So maybe I'm biased. But it's my claim that a student with concepts under his/her belt will be able to pick many more languages faster than the student having had a tutorial course. Mike Jipping Internet: jipping@cs.hope.edu Hope College BITNET: JIPPING@HOPE Department of Computer Science Voice: Hey!
wittman@athos.rutgers.edu (Barry) (08/16/90)
I agree with Jipping on the importance of concepts. Someone who knows how to program can do so in any language of a similar class to the one s/he has practised while learning. If one is merely exposed to a variety of languages and asked to write practice programs, what will happen is that bad techniques will be practiced and therefore learned. It is much harder to "unlearn" than to learn. The main issue we are concerned with in our foundations course is to answer the question: how can I implement the solution to a problem without getting lost or confused? The answer is to use good programing practices from the very beginning. It may be helpful for a student to be shown, in the first lecture, a few samples of what a program looks like in the language that is going to be used for practice, just to make it look less unfamiliar, but from then on I think concepts are what count. We try to stress structured programing concepts, top down design, functional modularity, right down to abstract data types. We expose recursion and iteration as approaches to problem solving. We try to do these things from the very beginning. This means we have to deal with functions and procedures, and the concepts of parameters/arguments, definition/reference, and recursion very early. And then show them in practice, with classroom examples as well as homework assignments in which the concepts are exploited. Actually writing the code is a late step in the process - in fact the next-to-last step (debugging is last). We sometimes ask our students to write the headers of all subroutines and functions prior to actually implementing them, if the program is requires several. The headers are turned in first as a separate assignment. (If our classes were smaller we could give individual guidance based on misconceptions revealed at this stage). We happen to use Pascal because it is characteristic of a wide class of languages, supports most of the concepts we are interested in reasonably well, and is widely available. We use the plain vanilla stuff, nothing exotic. The reverse approach doesn't work: students who know "BASIC" are at a serious disadvantage in many ways. Example: I once taught a high-level introductory course aimed at Math PHDs who were practicing faculty in State institutions trying to cross over to CS. One student had been using BASIC for 25 years and was so hopelessly mired in its limitations that he was unable to write Pascal programs. He was probably the worst example of someone burned by learning a programing language rather than programing. (He tried to write every assignment in BASIC and then translate to Pascal.) It's very hard to do Tower of Hanoi or even tree traversals in a non-recursive language, compared to the ease of recursion. Our second semester deals with data structures - still using Pascal, largely trees (general, binary, search trees, balanced, B-trees) with some graphs (pointers and linked lists having been introduced in the first semester). We also deal some with complexity analysis which is introduced in the first semester for simple cases. I hope this attempt is of some use to you. Barry Wittman Instructor
siegman@sierra.STANFORD.EDU (siegman) (08/17/90)
From wittman@athos.rutgers.edu: > >We try to stress structured programing concepts, top down design, >functional modularity, right down to abstract data types. We expose >recursion and iteration as approaches to problem solving. ...... >The reverse approach doesn't work: students who know "BASIC" are at a >serious disadvantage in many ways. ........ One student >had been using BASIC for 25 years and was so hopelessly mired in its >limitations that he was unable to write Pascal programs. . . . . >It's very hard to do Tower of Hanoi or even tree traversals in a >non-recursive language, Hopeless to try to get around people's ancient stereotypes, but modern BASICs (e.g., QuickBASIC) have ALL the standard structured programming concepts, along with global and local variables, recursively callable subprograms, and so on (and no more line numbers). Not saying that BASIC has everything Pascal, etc., have (esp. abstract data types), but one can (and obviously should) write structured, modular and top-down programs in BASIC also; and many people find it a lot easier and more rewarding to do so in BASIC than in Pascal.
rwallace@vax1.tcd.ie (08/19/90)
In article <1990Aug14.123438.9207@cs.hope.edu>, jipping@smaug.cs.hope.edu (Mike Jipping) writes: >> The point here >> is that perhaps you should concentrate on first teaching people a lot of >> different languages and then they'll be able to pick up the ideas. Say your >> students have learned a language like C which is suitable for software >> engineering. You could try giving them introductions to FORTRAN, COBOL, BASIC, >> Lisp, Forth, Algol etc. and hope they pick up some ideas of what programming >> languages are about. At the very least it'll teach them to appreciate the good >> qualities of whatever language they've been learning for mainstream programming >> :-). > > But it won't teach them much else... That method will give them the > mechanical ability to say "in this situation, I use C and in this > situation I use Ada", but it won't give them the ability to intelligently > CHOOSE a language which fill the application's need. > > For example, fully exploring concepts like data abstraction or static and > dynamic identifier scope will teach knowledge that a tutorial approach > never will. You can't "hope they pick up some ideas" and expect students > to learn what the "hole in scope" problem is and how to avoid it. > Learning CONCEPTS is the only way to adequately prepare a student for > big world of languages. > > That isn't to say that "first doing practice" must be avoided. Examples, > lab experiments, and programs programs programs can be given (and MUST be > given in a good course) to illustrate both the point of the current > concept and a particular way that a language implements a concept. > > I've taught a course in PL concepts for several years and a colleague and > I have authored a 1990 book on PL concepts. So maybe I'm biased. But > it's my claim that a student with concepts under his/her belt will be > able to pick many more languages faster than the student having had a > tutorial course. I agree that it's important to teach people concepts, but my point (I'm not sure whether you agree with it) is that you should teach specifics first and then generalize because people pick up examples much more easily than generalities. This is why children are taught arithmetic before algebra. "To summarize the summary of the summary: people are a problem" Russell Wallace, Trinity College, Dublin rwallace@vax1.tcd.ie
enbody@ss8.cps.msu.edu (Dr Richard Enbody) (08/21/90)
I teach a Programming Languages course using Pratt as a text, but skip most of the sections on specific languages. The course is a 10-week "quarter" course meeting 4 times per week. I handle the conflict of "languages tutorial vs. concepts" by teaching concepts in the class and by having the students learn two languages which are significantly different from the procedural languages which they are familiar with - Lisp and Prolog. Lisp is taught by handing out the "Little Lisper". It isn't modern Lisp, but covers the part of Lisp that is most different from Pascal. That book is completely self teaching - no class time is spent on Lisp (except for what comes naturally under the "concepts" part of the class). A similar technique is used for Prolog with the "Prolog Primer" book, but I find that one class is necessary for Prolog. Four programming assignments are given: exercises from the "LittleLisper", a Lisp Lexical Scanner (requires a Lisp "DO" loop), a Prolog "family tree" problem, and a Prolog Expression Parser. The assignments together are worth about 10% of the class grade, i.e. very little. The reason for teaching the languages is so the students can appreciate that there are other ways of programming than procedural programming. After playing with these languages they can appreciate some of the unique approaches to programming languages and can begin to appreciate what procedural and nonprocedural programming is all about. Time is also spent discussing Lisp machine architecture. The final two weeks are a compact compiler course built around a Simple Precedence parser with a quick overview of a few of the most important optimization techniques and some simple code generation. So what do they learn? They learn why languages look they way they do and what they are capable of. They know why FORTRAN is still around and which parts of it will never change. They can begin to appreciate nonprocedural programming - most find the "Little Lisper" to be fun and the _five line_ Prolog Parser really knocks them over. In addition, they learn the basic parts of a compiler. This is a tough course, but I find that the students enjoy it. Most interesting is that I have not had a single complaint about having them learn Lisp and Prolog on their own. I have taught it twice, and will teach it again this Fall. -rich enbody@cps.msu.edu