Newsgroups: comp.edu Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!decwrl!world!bzs From: bzs@world.std.com (Barry Shein) Subject: Re: Language Use In-Reply-To: thr1@ra.MsState.Edu's message of 14 Mar 91 05: 58:14 GMT Message-ID: Sender: bzs@world.std.com (Barry Shein) Organization: The World References: <1150@ra.MsState.Edu> Date: Thu, 28 Mar 1991 17:14:02 GMT Lines: 191 I don't teach now, but I taught programming courses in the Computer Science Dept (at Boston University) for a decade (until 1988). I've taught courses using 370/assembler, C, PL/1, and others ("Survey of Programming Languages", or "If it's Tuesday, this must be Cobol!".) I am very comfortable with most major programming languages, including Fortran, Lisp, C, etc. I've written extensive code professionally in many of those languages (the point being: my opinions don't stem from rumors about languages I've never actually used, and in many cases have taught.) That said, here are my opinions on the subject: The most important factors of a successful programming/teaching environment are a good book, an environment which follows the book, and of course a teacher who knows what they are doing (I'd rate knowledge and vision of computer science as a subject over sheer technical knowledge, tho some of each has its value.) A computer is a confusing, complicated environment to a new-comer. Not being able to type in a simple example from the book is exasperating and convinces a student that this is all impossible to ever master. It seems simple and obvious, but inevitably teachers adopt (e.g.) a Unix-oriented C programming book and then proceed to teach on the available campus mainframe which sort of has a C compiler. Of course, none of the file I/O works as advertised, the math libraries are strange and incomplete, link-editing and compiling involve mysterious voo-doo, none of the examples in the book will really work. The teacher gets overloaded trying to make up for these deficiencies with handouts, teaching assistants, user services people, and quickly spit-out notes in class ("on page 243 you'll have to use "rb" rather than "r" in the fopen() to get the example to work...on page 177 make the large auto array static or external...", you're laughing!, yeah, I've been there too.) Students get grumpy about always being one obscure detail short of getting an example to work, the whole thing invites disaster. (the same could be said for Fortran or Pascal or whatever, just an example.) It's really important to instill a sense of predictability and usefulness of written materials in students right away. They have to learn to find out information for themselves. If you badly mismatch the text and the environment you'll lose them forever, they'll never believe there's any relationship between what's written and what they actually need. Now, some opinions on languages and environments: 1. C - C is very easy to learn and teach. The key is not to introduce the advanced features right away. I've never had problems even later with pointers etc, but I think that's because I understand such topics deeply (I am a programmer at heart). I think most teachers who botch such topics tend to not understand them themselves and relay their own anxieties to their students. A little order and method is all that's needed. But there's absolutely no need to start with such topics. When you get to dynamic data structures they come up naturally enough. Just about any cliche in a so-called easier language can be taught in C, it's just a matter of style. Looping thru an array, character strings etc. In fact, I think the closeness of some of these topics to the machine is a good thing and highly abstracted languages leave students without a clue as to what is really going on inside a computer (of course, that assumes the teacher has a clue...) C is highly standardized, in a good environment a student can use additional texts if desired and be pretty confident that everything is relevant. Finally, there's an enormous amount of free source code available. Some should be made available and students should be encouraged to look at it, see how "real" people solve "real" problems. I can't overemphasize playing with and looking at others' code. Just its existence is immensely encouraging to a student, makes them realize the goal. They'll look at it because they'll think they can crib from it. That's fine, they'll have to understand it before they can crib. 2. Pascal - The problem with Pascal is related to my first recommendation, it's hard to find any agreement between any two books on just what Pascal is! Every implementation is chock-full of extensions and exceptions to make the basic language useable. This also makes it difficult to find a book which matches the locally available Pascal *AND* covers CS topics. Often one has to resort to at least two books, one which covers CS topics in Pascal and another which covers using the particular dialect available. The student is left with the chore of translating between the two books, very silly. Most pascals also have the problem of complicating or completely avoiding external linkage, at best it is pushed off to an advanced topic which is a terrible thing. Breaking a programming chore into modules (files), re-using them etc is an important lesson. It's sad to see this skipped simply because the compiler makes it difficult! I consider Pascal a dying language in general, mostly due to its astounding lack of portability (due to all the ideosyncratic extensions.) 3. Fortran - You'll have some problems finding a good CS book based on Fortran. This might be the result of the prejudices of the CS community, but it is a fact nonetheless. Fortran has few of the extension and knowledge-portability problems of Pascal (VMS Fortran excepted, which is barely Fortran tho most extensions can be successfully ignored, in its favor it is mostly a super-set and will compile standardized examples.) Environment excepted, if you know Fortran you know Fortran, most everything you know will work anywhere. Fortran's biggest flaw is its lack of data structures, and for the purpose of teaching Computer Science (I assume there's a bigger lesson being taught than the mechanics of programming) this flaw is just about fatal. Forget Fortran, offer a one-credit off-hours course to students with some programming background to pick this up later if they like. 4. ADA - Few compilers, mostly too expensive for academics to ever own, few books oriented towards CS, very demanding on the computing resources (usually precipitating battles between the people who teach and those who run the computers as the intro class makes the system unusable), oh well. DOD et al blew it with ADA by not making ADA environments available (thru grants etc) to educators. Right now it's mostly non-existent in academia, and the few faculty I know who insisted on teaching with ADA had to be heroes with raising money to support their courses. So its suitability as a teaching language is mostly moot, you don't own it, and you can't afford it. 5. Modula - I suspect there are still no CS texts based on Modula, so there's a problem. At least one free compiler (for Unix) exists, tho you'll have to support it yourself. The language does look promising as a teaching language, tho it doesn't seem to really exist. I doubt you'll find much environment to deal with Modula, not sure how much you really need (a debugger?) 6. Lisp/Scheme - Probably the most under-rated teaching languages, but you'll never fix that. Abelson & Sussman is an excellent text. It's not the choice of the trade-school/resume crowd since these languages are just not used much "out there". Wonderful environments, usually free, quite standardized etc. But you won't use it, you don't understand the language yourself, so who are we kidding? 7. ML/Logo/others - Huh? If you drive an electric car and lean towards macrobiotics and seances these might have some appeal. 8. C++ - Worth considering, I don't consider it "object-oriented", but it is an interesting language, more like Algol/68 done right. G++ can be had for free, a real plus (pardon me.) Probably hard to find a text tho I wouldn't be shocked to hear one exists at this point. I might be more inclined to start students out with C and then, perhaps in a second term, move to C++. That combination would be a real service to students, there's a lot of interest in both "out there", lots of papers on C++ also which might be worth introducing as material as you go on. Many of the interesting extensions of C++ over C are real, hard-core CS topics worthy of discussion and natural lessons in data abstraction etc. ---------- A final note: A nice way to teach an intro programming course is to assign lots of little, tiny projects each incorporating a cliche and slowly building skills. Programming is learned by drilling, in a way. Practice. Get them to realize that it's mostly a matter of matching the problem at hand to a particular cliche they've seen before. Build on that rather than getting macho and trying to get them to write big applications (the inevitable text editor) before they've realized that big programs are made out of lots of little, well-understood pieces. Teach them early how to link to libraries and exploit the terrain. If possible, use windowing libraries as a motivator (writing a few non-standard but simplified library routines is fine, give them the source!) Encourage them to explore and experiment, make it clear you'll like little variations on the assignments, reward them for it. (I realize in over-loaded environments this is hard, well, try some controlled variations and have them hand them in after doing the basic assignment for extra-credit or whatever.) -- -Barry Shein Software Tool & Die | bzs@world.std.com | uunet!world!bzs Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD