adb@elrond.UUCP (11/11/86)
In article <11577@watnot.UUCP> jjboritz@watnot.UUCP (Jim Boritz) writes: >In article <1087@burl.UUCP> rcj@burl.UUCP (Curtis Jackson) writes: >>>Very few CS courses provide marks for things like style. Sure you will >>>lose marks if your programs are not clear, but not for bad sytle. >> >> >>The above not only taught people how to comment meaningfully, it also >>prevented them from putting things in their code that were incredibly >>ugly, non-functional, or downright wrong -- "I don't know what the following >>2 lines of code do, but the program won't work without them." > >I was a tutor for an assembly language course a few months ago. When a >student does not know that part of their code is wrong, what is to prevent >them from putting this wrong piece of code in their programs. > > > ... > >At the end of it all you are still forced to give marks out for the parts >that worked. > >Jim Boritz > A couple of years back I TA'd some courses at U of New Hampshire, in which I tended to find that there were definately 3 types of programs submitted: those that didn't work, those that worked but weren't 'correct' in some manner, and those that were 'correct'. The first type is obvious, the second describes those programs that ran correctly against any input, but were not coded using the guidelines set forth (no goto's, well commented, using the proper methods being taught & etc.). The latter type (believe me) were few and far between. My biggest headache in grading the middle group was in trying to fairly place them in the propper position with respect to the other programs submitted. Let me explain, say program #1 ran well against the test suite, but used poor variable names, few comments and the like - but it was quite in line with the purpose of the exercise; meanwhile a second program (#2) was submitted, that also ran well, was much better commented but it did not accomplish the purpose of the exercise: eg. it did not use an array of records, but a group of arrays of different types. How do you place the programs relative to each other? Did you side with #1 because it better fit the assignment goal? Or with #2 as it was clearly better styled? I guess the question comes down to: Were we trying to reward students for better programming 'style' or for learning the concepts of the course at hand? Alan D. Brunelle uucp: ...decvax!elrond!adb | "To do all the talking and not phone: (603) 885-8145 | to be willing to hear anything us mail: Calcomp/Sanders DPD | is greediness" (PTP2-2D01) | Democritus Hudson NH 03051-0908 |
V6M@PSUVM.BITNET (11/13/86)
<>
I usually grade the programs such that
1. the program must work if not it is rejected outright.
2. then enforce style and intent of the structures defined.
3. let the student resubmit until it is working and well structured.
4. use a checksheet for each program and have the student submit it each
time. always use the same sheet until the code is accepted.
Vince Marchionniedwards@uwmacc.UUCP (mark edwards) (11/14/86)
In article <8448V6M@PSUVM> V6M@PSUVM.BITNET writes: ><> > >I usually grade the programs such that >1. the program must work if not it is rejected outright. >2. then enforce style and intent of the structures defined. >3. let the student resubmit until it is working and well structured. >4. use a checksheet for each program and have the student submit it each > time. always use the same sheet until the code is accepted. > Those are a good theoritical set of rules, probably applicable to courses like English, or a foreign language. I myself in English 101 had to at times rewrite a paper until it was grammatically and formally correct, and what not. But in Computer Science that is not always easy to do. In the earlier classes programs are small, but the knowledge level and experience of students is also small. Programming is usually a time consuming task. Sure for those whose only interest (or only class is that one Computer Science class) they have plenty of time to do it. Or at Universities like Madison, Graduate Students can some time get credit for taking undergraduate computer classes, where their load is 3 classes and the undergraduate is 4 classes, and usually undergrads must take 5. There are severe time constraints, at least for the undergraduates who are fighting with the grad students for grades. Now I had a class in operating systems, with a mixture of grads, and undergrads. The programming assignment was the same as the previous N operating systems class of semesters gone by. Our Prof decide that he would make it different. In previous classes once they completed a project everyone was given a correct solution to proceed on with the building of the next part of a toy operating system, in our class we were supposed to use our own code from stage 1. Do you get the picture, if your code did not work for part 1, it wasn't going to work for part2. Even if your code did work for part 1 it still may not work for part2. And so on. You could potentially get to the last part and have the entire thing blow up on you because of some thing you did in the previous sections. Some people had friends who had already taken the course before, some people had taken the course before and had dropped midway, some people were good programmers and got the problem right the first time (maybe by luck or by asking the right questions, or just by being themselves). And to top that off, the computer lab decided to put the brand new beta test release of 4.3 on the VAX, we experienced load averages usually in the 30's, sometimes higher. After submitting a job you had to wait 30 + minutes ( on an interactive terminal ) for it to compile and link and this was usually at any time in the day !!! Needless to say it was an experience. mark -- {allegra, ihnp4, seismo}!uwvax!uwmacc!edwards UW-Madison, 1210 West Dayton St., Madison WI 53706
V6M@PSUVM.BITNET (11/20/86)
<>
Let me clarify my position.
1. I teach MIS & DP courses mostly, so I don't assign problems whose
solutions are input to the sucessful completion of a project.
2. DP/MIS shops run on the theory of "get it working...period". There are NO
close enough solutions out here.
3. I keep the number of assignments DOWN to a managable few while making the
problems NON-trivial.
4. Workload for the student is easier but harder for me.
5. I do the same procedure whether or not I teach MIS or systems programming.
Remember the check sheet gives a RUNNING score for the program. The
student may stop the corrections at any grade he is happy with.
6. Points are cumulative and the final letter grade is determined by
total points in the course. I build a curve into the table.
Honest it works.
Vincent Marchionniron@brl-sem.UUCP (11/23/86)
In article <8612V6M@PSUVM>, V6M@PSUVM.BITNET writes: > <> > Let me clarify my position. > 1. I teach MIS & DP courses mostly, so I don't assign problems whose > solutions are input to the sucessful completion of a project. > 2. DP/MIS shops run on the theory of "get it working... This "DP/MIS" approach will get shops into trouble in todays market place. If a competetive environment and the advent of UNIX, you can expect the next slicko computer that the company buys is not going to be architecturily comapatible with the current one. The problems are magnified if you are actually in the SOFTWARE business where your programs are expected to work on UNIXs of many hardware flavors. -Ron
uh2@psuvm.bitnet.UUCP (11/24/86)
In article <495@brl-sem.ARPA>, ron@brl-sem.ARPA (Ron Natalie <ron>) says: >In article <8612V6M@PSUVM>, V6M@PSUVM.BITNET writes: >> <> >> Let me clarify my position. >> 1. I teach MIS & DP courses mostly, so I don't assign problems whose >> solutions are input to the sucessful completion of a project. >> 2. DP/MIS shops run on the theory of "get it working... > >This "DP/MIS" approach will get shops into trouble in todays market place. >If a competetive environment and the advent of UNIX, you can expect the next >slicko computer that the company buys is not going to be architecturily >comapatible with the current one. The problems are magnified if you are >actually in the SOFTWARE business where your programs are expected to work >on UNIXs of many hardware flavors. > >-Ron I agree entirely. The entire point of modern Software Engineering is to produce working software with the cheapest long-range cost. The "DP/MIS" approach will lose in the long run. lee
V6M@PSUVM.BITNET (11/25/86)
<>
Rebuttal sort of..
1. I don't agree with the prevalent MIS attitude of get it working first and
elegant or rigorous later. I teach MIS courses such that it is practical
, well done but not necesarilly rigorous AND THAT IT WORKS. It MUST
always work.
2. I agree that the prevalent MIS attitude has gotten most DP shops into
trouble...we ARE paying for it. The best I can do is prep my students to
fight the good fight.
3. As for hardware and o/s...rarely do we change once installed. If UNIX is
going to make it big it better run under VM!!!
Cheers
Vinceron@brl-sem.ARPA (Ron Natalie <ron>) (12/05/86)
In article <8704V6M@PSUVM>, V6M@PSUVM.BITNET writes: > > 3. As for hardware and o/s...rarely do we change once installed. If UNIX is > going to make it big it better run under VM!!! > Hardly. I don't know what MIS shop you work in, but if the hardware didn't change underneath there wouldn't be any need for autocoder or VM. The main reason VM is a product from IBM is so that MVS can be run on the newer/faster CPU's. -Ron By the way, you can run UNIX under VM.
bzs@bu-cs.BU.EDU (Barry Shein) (12/05/86)
>Hardly. I don't know what MIS shop you work in, but if the hardware >didn't change underneath there wouldn't be any need for autocoder or >VM. The main reason VM is a product from IBM is so that MVS can be run >on the newer/faster CPU's. > >-Ron Huh? Most shops don't run MVS on top of VM, especially on the newer/faster CPUs for two reasons: 1. It's a performance hit, not much, but 10% (which I think is a fair estimate) of an $8M 3090 is significant. 2. VM won't support MVS/XA (extended architecture), or at least not yet, or at least not recently, I know XA support in VM is promised but for years it wasn't available. VM basically supports a machine environment (such as trapping and emulating all priv'd instructions), not the architecture, all non-priv instructions (give or take memory accesses) run on the raw machine even under VM. IBM keeps implementing the 370 architecture on different hardware (and also did so with the 360 architecture) but VM does little if anything (I am sure there are nits to pick here) to bridge the difference, that's below VM. But yes, there are at least two versions of UNIX which run under VM, IX/370 from IBM and AMDAHL/AT&T/UTS. -Barry Shein, Boston University
ken@argus.UUCP (Kenneth Ng) (12/06/86)
In article <504@brl-sem.ARPA>, ron@brl-sem.ARPA (Ron Natalie <ron>) writes: > -Ron > > By the way, you can run UNIX under VM. I don't see why not, Unix is just an application program as far as VM is concerned. -- Kenneth Ng: Post office: NJIT - CCCC, Newark New Jersey 07102 uucp !ihnp4!allegra!bellcore!argus!ken *** WARNING: NOT ken@bellcore.uucp *** !psuvax1!cmcl2!ciap!andromeda!argus!ken bitnet(prefered) ken@orion.bitnet Kirk (about Spock): "He took too much LDS in the 60s"
hes@ecsvax.UUCP (Henry Schaffer) (12/08/86)
In article <2796@bu-cs.BU.EDU>, bzs@bu-cs.BU.EDU (Barry Shein) writes: >... > > Huh? Most shops don't run MVS on top of VM, especially on the newer/faster > CPUs for two reasons: >... > 2. VM won't support MVS/XA (extended architecture), or at least > not yet, or at least not recently, I know XA support in VM > is promised but for years it wasn't available. >... > > -Barry Shein, Boston University Some non-IBM literature I received recently (Which VM is Right for You, by VM Software, Inc. of Reston VA) lists a whole bunch of VM "variations" from VM/SP-Entry or VM/IS at the bottom end (simplest with limited capabilities - assuming we're not counting VM/PC) to VM/SF (originally VM/XA in its first release) which is "At the highest end of VM variations...". This gives the capability of converting from, e.g. MVS/SP to MVS/XA and having both systems running all the time during the conversion. This is an incredible benefit during the conversion time - for testing during business hours, parallel runs, etc. --henry schaffer n c state univ
arnold@emory.UUCP (Arnold D. Robbins {EUCC}) (12/08/86)
In article <2440@ecsvax.UUCP> hes@ecsvax.UUCP (Henry Schaffer) writes: >> [quotes by Barry Shein that MVS/XA not supported under VM deleted] > > Some non-IBM literature I received recently (Which VM is Right for You, >by VM Software, Inc. of Reston VA) lists a whole bunch of VM "variations" >from VM/SP-Entry or VM/IS at the bottom end (simplest with limited >capabilities - assuming we're not counting VM/PC) to VM/SF (originally >VM/XA in its first release) which is "At the highest end of VM variations...". > > This gives the capability of converting from, e.g. MVS/SP to MVS/XA >and having both systems running all the time during the conversion. This >is an incredible benefit during the conversion time - for testing during >business hours, parallel runs, etc. > >--henry schaffer n c state univ The way I understand it from talking the IBM-ers around here, is that on an XA machine, VM/SF allows an XA guest, but that is about it; i.e., otherwise it is a very stupid VM, with only a rudimentary CMS. We have been considering a 3090 class machine at the Computing Center, and if we were to get one, the set up would eventually be: +---------+ +-----------------+ | CICS... | | CMS, IX/370 ... | +---------+ +-----------------+ | MVS/XA | | VM/HPO | +---------+---+-----------------+ | VM/SF | +-------------------------------+ | 3090 Hardware | +-------------------------------+ Short term, it would probably be like this: +---------+ +--------+ +-------------+ | CICS | | CICS | | VM stuff... | +---------+ +--------+ +-------------+ | MVS/XA | | MVS/SP | | VM/HPO | +---------+---+--------+----------------+ | VM/SF | +---------------------------------------+ | 3090 Hardware | +---------------------------------------+ This would be for testing and conversion, in particular between the two MVS systems. Boy, I'm glad I'm not an IBM jock... -- Arnold Robbins CSNET: arnold@emory BITNET: arnold@emoryu1 ARPA: arnold%emory.csnet@csnet-relay.arpa UUCP: { akgua, decvax, gatech, sb1, sb6, sunatl }!emory!arnold
eugene@nike.uucp (Eugene Miya N.) (12/09/86)
Re: comments about Running Unix on on VM.
I spoke with a person reasonably high in IBM. He tell me the clammer is
not for Unix on VM anymore. Apparently people are asking for VMS on VM.
Interesting problem for IBM.
From the Rock of Ages Home for Retired Hackers:
--eugene miya
NASA Ames Research Center
eugene@ames-aurora.ARPA
"You trust the `reply' command with all those different mailers out there?"
{hplabs,hao,nike,ihnp4,decwrl,allegra,tektronix,menlo70}!ames!aurora!eugenebzs@bu-cs.BU.EDU (Barry Shein) (12/09/86)
From: eugene@nike.uucp (Eugene Miya N.) >I spoke with a person reasonably high in IBM. He tell me the clammer is >not for Unix on VM anymore. Apparently people are asking for VMS on VM. >Interesting problem for IBM. Hmm, a well set-up 3090 could probably emulate an 8600 faster than an 8600 could...nah, c'mon...hmmm...a little microcode...then there's those channels...nah..hmmm I was under the impression that IBM got into the whole UNIX game mainly because of the $1B NSA contract they had to withdraw themselves from as bidders because it required UNIX. I will say that I mentioned that to an IBM "higher up" and his answer was (thoughtfully, brow knitted, quietly and slowly) "no, I don't think that's right, federal systems doesn't recommend UNIX to NSA..." Made me turn around my attitudes a little (but I still think that's right, about the lost NSA contract, $1B ain't much to them, but it probably seemed like a disturbing trend.) -Barry Shein, Boston University