Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-lcc!styx!ptsfa!hoptoad!academ!killer!elg From: elg@killer.UUCP (Eric Green) Newsgroups: comp.edu Subject: Re: Assigning the same Programming Assignments every time Message-ID: <818@killer.UUCP> Date: Thu, 30-Apr-87 02:15:01 EDT Article-I.D.: killer.818 Posted: Thu Apr 30 02:15:01 1987 Date-Received: Thu, 7-May-87 06:29:06 EDT References: <509@ai.WISC.EDU> Organization: The Unix(tm) Connection, Dallas, Texas Lines: 49 in article <509@ai.WISC.EDU>, neves@ai.WISC.EDU (David M. Neves) says: > >>> Why do professors assign the *SAME* problems every semester anay? >>Because they're just like you and me: *LAZY*!!! Let's face it, >>if they don't have to, why bother? > > Sigh... Do you know how long it takes to design a good assignment? > When students enjoy an assignment and it gives them good training why > through it out? I try to change it just enough to discourage (or > detect) cheating. One instructor here assigns the same assignment every year in her assembly language class -- implement a simulator for machine "A" (insert handout here, with specifications of machine), and run it with sample machine language program "B" (insert another handout here). And do it all in the assembly language of machine "C" (was a Pyramid 90x for three years, now it's an IBM 3090). The assignment has much merit as a "weeding-out" period. People who cannot design software certainly aren't going to write a sizable assembly language program. The way she deals with the problem of programs from last year is to change up addressing modes, instructions, registers, etc. of the simulated machine, every year (and changing the sample machine language program for that machine, of course). > If the same assignment is kept it could then be made easier. Because > of the feedback given this semester the program description could be > made better. > > I think that instructors and students both gain when assignments are > improved over time. Definitely. Each year, her machine design is better specified (when I took the course, years ago, she had a bunch of ambiguities and ended up having to write a new specification of the indirect addressing modes). It's very hard to write a specification that is clear and concise the first time through.... once you write it, someone inevitably says "well, what about special case #n? How do you do xyz? does it add the index before or after the indirection?" and other such words of praise :-). I've ended up re-writing major parts of BT's documentation after a couple of beta-tester customers got ahold of it and started on that (groan....). -- Eric Green elg%usl.CSNET CS student, University of SW Louisiana {cbosgd,ihnp4}!killer!elg Apprentice Haquer, Bayou Telecommunications Snail Mail P.O. Box 92191 BBS phone #: 318-984-3854 300/1200 baud Lafayette, LA 70509 Clever quote goes here, but I'm out of room!