jxs7451@ritcv.UUCP (03/11/86)
This article has to do with working programs in CS courses. In my past
experience with CS courses it seems that alot of u-grads do not get their
programs done correctly. This, of course is very common, but when the
the grades came back, i have been quite suprised.
For a program that does not compile, and has good style, i have seen people
get 65 %, and with compilation get 75%. Of course the program turned in
must be reasonably long, and look like it might do something close to what
was assigned.
To me this doesn't seem right, i mean that the program should be atleast
able to compile, and start to do something. Obviously many people are
not going to get to all of the special cases, or maybe skip a part, but
students were just going to the lab and typing for 5 hours to get a reasonable
length thing and hand it in with good style, and pass(with a D).
Any opinions about this out there?
jeff "in sunny downtown Rochester"(or something like that)
UUCP: {allegra,seismo}!rochester!ritcv!jxs7451
CSNET: jxs7451%rit@csnet-relay.ARPA
BITNET: JMS7451@RITVAXCbeth@umcp-cs.UUCP (Beth Katz) (03/13/86)
jeff writes: >This article has to do with working programs in CS courses. In my past >experience with CS courses it seems that alot of u-grads do not get their >programs done correctly. This, of course is very common, but when the >the grades came back, i have been quite suprised. > I'm new at teaching, but I knew a lot of students would be turning in programs that didn't work perfectly. What I didn't know was that only four programs out of 29 would pass my tests. Obviously, the programs weren't the only thing that was wrong. :-) I thought about it, decided that perhaps the students were not comfortable with the language (Ada), the operating system (UNIX), the editor (vi), the time to finish the problem (1.5 weeks), the specs for the changes (they were modifying some programs), or some combination of those. I decided to describe the failures and ask them to fix them. I hope that's a better learning experience. The class has both grads and undergrads. A friend and I have contemplated giving 0/1 grades on programs. Students often change the problem to suit their solution or decide that partial credit is enough. We definitely want to encourage good programming style, but we want programs that work. For example, my students were unhappy with the commenting and style of some the programs they were changing. In most classes, these programs would have earned fairly reasonable marks for style. I hope that when the students write their own programs, they will remember this assignment and comment more effectively. But having a program work is also very important. Sometimes I just think we've gone overboard in stressing style over correctness. The 0/1 grading has problems, but when I was an undergrad (at William and Mary), one professor was so annoyed that most of the class couldn't answer a question about BNF on a midterm that he gave us a project. We had to write a SNOBOL program (if I remember correctly) to read in a BNF grammar and generate a recognizer for the language described by the grammar. Our grade on the program (0 or 1) would be multiplied by our final grade. EVERYONE managed to get that program to work. And I would bet every one of us remembers at least something about BNF, if not SNOBOL. Maybe having students fix the faults in their programs would be good for them. Maybe stressing the need to develop test cases (input and output) and checking the program before turning it in would help. Maybe writing better specifiactions would help. But giving the majority of the credit for style doesn't seem to be the answer. Beth Katz Univ. of Maryland C S Dept. -- These opinions are my own. This department surely wouldn't make -- -- me its spokesman. Power and graduate students don't mix. :-) -- -- This doesn't mean that "the-powers-that-be" don't listen to us. --
larry@kitty.UUCP (Larry Lippman) (03/14/86)
In article <9431@ritcv.UUCP>, jxs7451@ritcv.UUCP writes: > This article has to do with working programs in CS courses. > > For a program that does not compile, and has good style, i have seen people > get 65 %, and with compilation get 75%. Of course the program turned in > must be reasonably long, and look like it might do something close to what > was assigned. > > To me this doesn't seem right, i mean that the program should be atleast > able to compile, and start to do something. Obviously many people are > not going to get to all of the special cases, or maybe skip a part, but > students were just going to the lab and typing for 5 hours to get a reasonable > length thing and hand it in with good style, and pass(with a D). > > Any opinions about this out there? By gum, if you're taking a CS course, an examination program better not only compile, but show some damn good function! What have you learned if all you can do is write non-functional "stylized" lines of code that will not even (ohmygod!) compile? There is no excuse for someone who is so ignorant, lazy and/or sloppy that a program will not compile. ==> Larry Lippman @ Recognition Research Corp., Clarence, New York <== ==> UUCP {decvax|dual|rocksanne|rocksvax|watmath}!sunybcs!kitty!larry <== ==> VOICE 716/741-9185 {rice|shell}!baylor!/ <== ==> FAX 716/741-9635 {G1, G2, G3 modes} duke!ethos!/ <== ==> seismo!/ <== ==> "Have you hugged your cat today?" ihnp4!/ <==
ins_asac@jhunix.UUCP (Stephan Alexa Cooper) (03/14/86)
In article <244@umcp-cs.UUCP> beth@maryland.UUCP (Beth Katz) writes: >jeff writes: >>This article has to do with working programs in CS courses. In my past >>experience with CS courses it seems that alot of u-grads do not get their >>programs done correctly. >> >I'm new at teaching, but I knew a lot of students would be turning in >programs that didn't work perfectly. What I didn't know was that only >four programs out of 29 would pass my tests. Obviously, the programs >weren't the only thing that was wrong. > >Maybe having students fix the faults in their programs would be good >for them. Maybe stressing the need to develop test cases (input and >output) and checking the program before turning it in would help. >Maybe writing better specifiactions would help. But giving the majority >of the credit for style doesn't seem to be the answer. I think having the students fix their programs is a great idea. A good practice would be to follow the lead of other courses, and require that to pass the course, ALL assignments be completed, whether on time or not. The grade that the student receives for the assignment will be the grade that his/her assignment earns on the deadline. This would require the student who passes the course, regardless of the grade received, to actually solved ALL of the assignment problems, and experience debugging (using test cases, etc.). I have an elective that does just this. In order to pass we MUST do ALL of the homework. If it's late, we will get the 0 ('F') for the assignment, but we still have to do it. If we don't, we don't pass. Now, I am not a grad student or a prof. I guess then, you can see I'm an undergrad. But still I support this practice. After all, it makes me overcome the assignment, whether by the deadline or not. As for the majority of grading on style, you've got to be kidding! I grant, style is VERY important, but if the program doesn't work, style's not going to make it work any better. Pretty programs do not always work best. How are you going to give a good grade to a program that is supposed to (for example) manipulate lists of structures (C) if it only looks good, but doesn't work? Style should be considered AFTER the making the program work. I don't mean "write the program, get it to work, then re-structure it to make it look good." That idea is absurd. I think we can agree that style should be hand-in-hand with writing the program. It is for me, in fact very often it is style that keeps me from just rattling off a program. What I mean is that in the grading process, style should be that thing which decides whether the program is an 'A' or 'B.' -- Steve Cooper Johns Hopkins University Electrical Engineering and Computer Science ...!seismo!umcp-cs!jhunix!ins_asac
mazlack@ernie.berkeley.edu (Lawrence J. Mazlack) (03/15/86)
>>This article has to do with working programs in CS courses. In my past >>experience with CS courses it seems that alot of u-grads do not get their >>programs done correctly. This, of course is very common, but when the >>the grades came back, i have been quite suprised. >> >I'm new at teaching, but I knew a lot of students would be turning in >programs that didn't work perfectly. What I didn't know was that only >four programs out of 29 would pass my tests. Obviously, the programs > > Beth Katz Giving partial credit for non-working programs is a curse that comes from other disciplines. I maintain they are almost impossible to evaluate as to the closeness of completion - how many times have you said "just one more run" about 20 or a 1000 runs before success. I usually try to relate the issue to whether or not they would want to buy a non-working program with their own money. I also ask the question as to whether they would like to have a surgeon who almost has living patients. What I do, is to establish a rule that the MAXIMUM value of a non-working program is worth 5-10% of a working program. Then, the program is graded according the other standards (internal documentation, coding standards, presentation of results, etc) and that grade is multplied either by 1 or 0.1 (for non-working programs). Needless to say, non-working programs usually fail to meet some of the other standards. The only reason that I even give the 0.1 or 0.05 multiplier is because of the whining. Larry Mazlack UUCP {tektronix,dual,sun,ihnp4,decvax}!ucbvax!ucbernie!mazlack New style mazlack@ernie.berkeley.edu ARPA | CSNET mazlack%ernie@berkeley.ARPA BITNET mazlack@ucbernie.BITNET telephone (415) 528-0496 snail CS Dept, 571 Evans, U. California, Berkeley, CA 94720
jxs7451@ritcv.UUCP (03/15/86)
Let me add a little more on the subject, because my last article may
have been a little unclear.
I thing that the 0/1 grading is not right. There are other things
like style, and the rest that are important. But the thing that
scares me is there is a very good chance that there are graduating
CS majors that have never wrote a program that worked entierly.
This, if i were an employer would tend to scare me.
But the problems that occured in the class that i mentioned before
were, i feel, were particually bad. Students were handing in
programs that **would not compile**. I'm not talking about little
things like(this was Pascal) "varx is neither used or set", it was
in some cases things like that generate "Error code 1. Stop."
I know that this is not like this in all CS courses here at RIT,
but in this particular class wanted to do no work, and the
professor let them get away with it more or less. And this was
a course that required about 1200 - 1500 lines of Pascal. If i can
say so, people were handing in stuff that desirved no more than
20 percent, were getting 65's.
About the straight A student that coulnt program his way out of a
paper bag, i don't know. It sort of scares me the way some
Universities work today, but then again i guess i am a cynic.
jeff "in sunny downtown Rochester"(or something like that)
UUCP: {allegra,seismo}!rochester!ritcv!jxs7451
CSNET: jxs7451%rit@csnet-relay.ARPA
BITNET: JMS7451@RITVAXC
"Anything i said here was not hllped by the s`*$$y phone line i'm on"lamy@utai.UUCP (Jean-Francois Lamy) (03/16/86)
Programs that do not compile should not be marked (i.e zero).
(With the possible exception of the very first assignement in
a computer illiteracy course).
--
Jean-Francois Lamy
Department of Computer Science, University of Toronto,
Departement d'informatique et de recherche operationnelle, U. de Montreal.
CSNet: lamy@toronto UUCP: {ihnp4,utzoo,decwrl,uw-beaver}!utcsri!utai!lamy
EAN: lamy@iro.udem.cdn ARPA: lamy%toronto@csnet-relayliberte@uiucdcsb.CS.UIUC.EDU (03/17/86)
I agree strongly with Beth's idea of having students fix their mistakes. As she says: /* Written 9:45 am Mar 13, 1986 by beth@umcp-cs.UUCP in uiucdcsb:net.cse */ ... I decided to describe the failures and ask them to fix them. I hope that's a better learning experience. .... Maybe having students fix the faults in their programs would be good for them. ... Beth Katz Univ. of Maryland C S Dept. /* End of text from uiucdcsb:net.cse */ I firmly believe that we need to move the entire educational system (especially at the lower levels) towards a corrective approach. There are many reasons I feel this way. All in all, the goal is better education. If students need to learn something in order to understand something else, why let them get away with less? However, some students will need more time than others. So give them time, as long as they are making progress. At the same time, some students are prepared to zoom on through the material, so why slow them down? This path leads towards more independent study as opposed to rigidly timed class study. My feeling when I get a graded assignment or test back is primarily frustration. I am sloppy, I admit, and almost always make dumb mistakes. Depending on the grader, a mistake early in the solution to a problem may result in everything dependent on that mistake being marked wrong. Does this mean I dont understand how to solve the problem? Sometimes yes. But if I misunderstood, dont I need to learn the material anyway? And if so, shouldnt I be given the chance to prove that I have learned the material? Teachers and TAs make mistakes too. They ask ambiguous questions, or forget to cover some material in class, or run out of time and do a sloppy job. By not making grades so final, no one loses quite so much by anyones mistakes. Time is lost, of course, but more time is lost in the long run by not correcting mistakes early. There is much more to say on this subject, but I will save it til later. Dan LaLiberte liberte@b.cs.uiuc.edu liberte@uiuc.csnet ihnp4!uiucdcs!liberte
dick@ucsfcca.UUCP (Dick Karpinski) (03/17/86)
In article <2213@jhunix.UUCP> ins_asac@jhunix.ARPA (Stephan Alexa Cooper) writes: >>Maybe writing better specifiactions would help. But giving the majority >>of the credit for style doesn't seem to be the answer. > >As for the majority of grading on style, you've got to be kidding! I grant, >style is VERY important, but if the program doesn't work, style's not going >to make it work any better. Pretty programs do not always work best. >How are you going to give a good grade to a program that is supposed to >(for example) manipulate lists of structures (C) if it only looks good, >but doesn't work? Style should be considered AFTER the making the program >work. I don't mean "write the program, get it to work, then re-structure > ... >What I mean is that in the grading process, style should be that thing which >decides whether the program is an 'A' or 'B.' I do not agree. First of all, there are very few programs that work. That is, a program which is said to work should have a specification. Few specifications exist. There is a whole lot of "you know what I mean" in the attempts I see. In light of these facts, the exact correspondence between specification and implementation is hard to assert. Secondly, the task is not even that easy. Several deep thinkers about computer programming point out that the design of a program should establish the basis for a whole family of related programs. The essence of that claim is that the outside world keeps changing and demanding alterations to the function to be served. A program which perfectly meets its initial specs but cannot be altered is of little value. Thirdly, the test-it-till-it's-perfect school fails badly. Almost any real program is entirely too complex to test comprehensively. Just consider the combinatorial effects of taking say three full word parameters. The universe has ended before the testing is complete. I won't claim that good style is enough, but I would sure rather fix and then change a clearly written program which fails than to try to change a correct program which I cannot understand. In particular, Michael Jackson's approach appeals to me. He says to build the program around a model of the situation in which the program lives, rather than to perform the requested function. Then the changes in requested function can be accomodated easily, since they are mere window dressing on a well constructed skeleton which remains clear and clean. Remember that we are not writing programs to get the computer to do the right thing! Instead, we write programs to make the next guy's job easier; to facilitate the inevitable changes. The first thought should be to make the program obvious to the casual reader. Bugs in such programs are not the major problem that they so often are in more conventional (bad) programs. I hope that there is at least something controversial above. Dick -- Dick Karpinski Manager of Unix Services, UCSF Computer Center UUCP: ...!ucbvax!ucsfcgl!cca.ucsf!dick (415) 476-4529 (12-7) BITNET: dick@ucsfcca Compuserve: 70215,1277 Telemail: RKarpinski USPS: U-76 UCSF, San Francisco, CA 94143
mc68020@gilbbs.UUCP (Tom Keller) (03/18/86)
Dick Karpinski makes some interesting points. In essence (please correct
me if my summary misrepresents what you are saying, Dick) what I understand
his position to be is as follows:
In as much as "real world" programs can never be fully tested, and in as
much as specifications for programming assignments tend to be nebulous at
best, he feels that style should be considered at least as important as
whether or not a program works. He argues maintainability, in essence.
Yes, Dick, I agree that programming students need to learn style. But
I disagree to the extent that a program which doesn't even come close to
performing the desired function, and which won't even pass through the
compiler should not carry any value. Many of the programs of this nature
to which we are referring are written by students who frequently are unable
to explain the intended operation of the code they have produced.
Style shouold certainly be considered when evaluating a programming
assignment, and emphasis on style is essential. But non-functional programs
(no programs which have minor problems, but totally non-functional) should
not be acceptable under any circumstances.
--
====================================
Disclaimer: I hereby disclaim any and all responsibility for disclaimers.
tom keller
{ihnp4, dual}!ptsfa!gilbbs!mc68020
(* we may not be big, but we're small! *)gds@mit-eddie.MIT.EDU (Greg Skinner) (03/19/86)
I have never taken a class where if your program didn't compile, you
got anywhere near 65% credit for it. Especially in my software
engineering class, where 40% is testing & documentation -- if your
program won't compile you can't test anything!
There are some colleges that don't give out grades. UC Santa Cruz is
one, there are probably others. I don't know if it is better not to
have grades because in some circumstances it can discourage you from
doing work. I used to say that it would be nice if I could just go to
university and study until I didn't feel like learning anymore, at my
own pace, instead of having to learn some minimum set of facts.
However, I suppose *some* metric muset be used by schools to
differentiate between students for admissions to graduate programs. I
wonder though, would most companies rather have someone who took 6 or
7 years to graduate, but learned enough about their subject to be
quite proficient in it, rather than someone who did the traditional 4
years but didn't learn everything they could have, and those gaps
showed up on the job?
--
It's like a jungle sometimes, it makes me wonder how I keep from goin' under.
Greg Skinner (gregbo)
{decvax!genrad, allegra, gatech, ihnp4}!mit-eddie!gds
gds@eddie.mit.edumangoe@umcp-cs.UUCP (Charley Wingate) (03/19/86)
I seem to be the one who got this notion about grading mostly on style
started. This is an important misunderstanding which I want to clear up.
This style-heavy grading is really only appropriate for the early courses,
and only when you expect to see most people complete the project. In any
case, their's an obvious limit to how much style can be worth. Ideally,
things should come out in this order:
1) Hopeless cases (bad style and no function)
2) Good style but non-functional
3) Functional but ugly
4) FUnctional and stylish
On some early projects, however, it seems like you need to reverse 2 and 3,
so as to discourage those who are just trying to get by from writing
"baling-wire specials".
As far as grading on functionality is concerned, I am a convert to grading
it hard. I'll even go further and insist upon the grader supplying test
data.
C. Wingaterb@ccivax.UUCP (rex ballard) (03/21/86)
In article <455@ucsfcca.UUCP> dick@ucsfcca.UUCP (Dick Karpinski) writes: >In article <2213@jhunix.UUCP> ins_asac@jhunix.ARPA (Stephan Alexa Cooper) writes: >>>Maybe writing better specifiactions would help. But giving the majority >>>of the credit for style doesn't seem to be the answer. >> >>As for the majority of grading on style, you've got to be kidding! I grant, >>style is VERY important, but if the program doesn't work, style's not going >>to make it work any better. Pretty programs do not always work best. > >I do not agree. First of all, there are very few programs that work. >That is, a program which is said to work should have a specification. >Few specifications exist. There is a whole lot of "you know what I >mean" in the attempts I see. This is a design problem. The teacher should be able to write a good complete specification of the problem, or the students should be able to complete it. The easiest specs are "here are inputs, this is what the outputs should be". >In light of these facts, the exact >correspondence between specification and implementation is hard to >assert. > >Secondly, the task is not even that easy. Several deep thinkers >about computer programming point out that the design of a program >should establish the basis for a whole family of related programs. >The essence of that claim is that the outside world keeps changing >and demanding alterations to the function to be served. A program >which perfectly meets its initial specs but cannot be altered is >of little value. Agreed, the ability to enhance a system is important. The solution is simple, assign the first spec, then assign the enhancements. That's how it's done in the real world :-). >Thirdly, the test-it-till-it's-perfect school fails badly. Almost >any real program is entirely too complex to test comprehensively. True, but most complex systems are built from "trivial units" or should be. These are quite easy to test. >Just consider the combinatorial effects of taking say three >full word parameters. The universe has ended before the testing >is complete. The typical industrial approach is to test with "known good" data, then "known bad" data, then "pseudorandom" data. Yes, there might still be a particular case where the algorythm won't work, but the chances of finding it in a standard functionality test are slim. Usually, these problems are things like "windows of error" where during a 5 us window something could theoretically go wrong (an interrupt corrupts the stack...). Even PDP-11 C compilers have this problem. >I won't claim that good style is enough, but I would sure rather >fix and then change a clearly written program which fails than >to try to change a correct program which I cannot understand. In one course, taught by the company training department, the teacher had us trade programs, THEN add an enhancement to the working code. We were evaluated based on how long it took the other person to change the original. It's a good assignment. >In particular, Michael Jackson's approach appeals to me. He >says to build the program around a model of the situation in >which the program lives, rather than to perform the requested >function. Then the changes in requested function can be >accomodated easily, since they are mere window dressing on a >well constructed skeleton which remains clear and clean. This requires that the model be acurate (functionally correct and working). If the original model is defective, the changes will be harder to make, reguardless of how "pretty" it is. >Remember that we are not writing programs to get the computer >to do the right thing! Instead, we write programs to make the >next guy's job easier; to facilitate the inevitable changes. While I won't deny that making "the next guy's job easier" is important, if "the next guy's job" is to fix old functionality before adding new, then the original is more expensive (we pay programmers) than it should be. >The first thought should be to make the program obvious to the >casual reader. Bugs in such programs are not the major problem >that they so often are in more conventional (bad) programs. I would love to tell you about all the "Beautifully Documented" programs that required six weeks to write and twelve weeks for the enhancer to understand, and required "fixing" almost weekly. This isn't as bad as badly documented code, but almost. Design (Yourdon, Jackson,...) should be a pre-requisite to building "complex" systems. If the student MUST learn a language first, then trivial tasks should be used to teach it. There are lots of good excercises in some of the old BASIC books which could be used for any language. > >I hope that there is at least something controversial above. There was. > >Dick