Re: Any research putting c above ada?

[huang@mnsinc.com (Szu-Wen Huang)]

Normally I wouldn't bother with a crossposted post that doesn't have
anything to do with the topics of any of the three groups, but somehow
the discussion turned into what is expected of software, and I think
that's marginally relevant.

Jonathan Guthrie (jguthrie@brokersys.com) wrote:
: In comp.lang.ada Craig Franck <clfranck@worldnet.att.net> wrote:

: > >> Yes, but the CS professor is teaching *CS* students, not simple end
: > >> users of software.

: > >How is there a difference?

: > It was mostly the attitude of the student that anything they needed 
: > to know should be handed to them on a silver plater with no effort 
: > on their part to learn about the software involved. A lot of the 
: > software used by developers has an "in house" almost beta release 
: > feel to it; it is not always like those ubiquitous AOL disks that 
: > fall out of almost every computer magazines.

: I can't judge the attitude of the student, but if I had a program that
: ate some important data and didn't let me know that it was doing it,
: I would be more angry with the idiot that coded that piece of crap
: than I would be at myself for not memorizing the manual.  Of course,
: I don't know how CS people think.  I'm an engineer by training.
[...]

Here we see two excellent and not mutually contradictory points.  Craig
is saying that a college student, especially one in CS, should have
enough initiative to know the relevance of documentation.  I don't
think Jonathan is actually disagreeing with that, though he makes it
sound like so by saying the software is to blame.

Jonathan, if you accidentally did a 'rm -rf' (recursive delete) at
work and delayed your project by months, do you blame the software?
Sure, rm didn't warn you, wasn't safe, was this and that - but the
point is that the damage is done and it's *your* responsibility.  I
think that's Craig's point - whatever caused it, the CS student must
take responsibility for not reading the manual, not asking the SA,
not asking the teacher.

Another example:  would you send a crucial (not necessarily secret)
piece of message through e-mail?  You might consider calling, or
explicitly asking for an acknowledgement, correct?  Now, if a student
did not receive an acknowledgement that both parts of his work are
received, what kind of students do we want to produce?  The kind that
sits on his ass and *assumes*, or the kind that finds out?

Do you not generally assume your compiler is correct, but not preclude
the possibility that it can be generating wrong output?

I don't think anybody is advocating that the CS student should be
given full credit because of a crappy program whose instructions he
did not read.  Sure, software can and should be better, but in the
end a person must take responsibility (not necessarily guilt, just
responsibility), and I don't think it's the person who wrote it.
 
: Part of the problem is that manuals are usually organized as reference
: material and usually do NOT contain information in a fashion that is
: easily absorbed.  (A "Monty Python" sketch involving lark's vomit leaps
: to mind and will not be elaborated upon, here.)

If the student has trouble understanding the documentation, I believe
there are people available to ask.  Lousy manuals aren't reasons to
skip all manuals.

: > >The program in question is defective, and should be fixed.  "Hand holding"
: > >or not, teaching programmers-in-training (which is what CS students are
: > >supposed to be) that it is a good idea for programs to overwrite data 
: > >without any indication that it is doing so borders on negligence, in
: > >my opinion.  

: > Maybe it is a bug in the beta release. Did he look for a list of
: > known bugs?

: I assign you a task:  Write, longhand, "Beta software should not be
: used in production situations" 500 times.  In the situation described,
: whoever chose to use beta software in that manner a fool, if the software
: was a beta.  Learning not to use the software in that case is more
: important than following directions.

If I didn't trust the programs the SA probably hacked together, I'd
make sure he got it.  In fact, back in school I read the Tcl source
code of our homework submission program, because ultimately it's *my*
grade.

Let me put it most clearly - it's somebody's fault the software isn't
production quality, and that failure might disqualify the person for
a teaching position (teaching the wrong thing, certainly).  It's another
person's fault the assignment wasn't turned in correctly.  The two
failures do not cancel each other out.

: If I were writing the program, a list of known bugs would not contain ANY
: mention of a situation where data was lost.  That is a "category 2" defect
: and cannot be allowed to exist in any situation where any end user might
: run into it.  Look, I don't think that the experience was as valuable for
: the user as it should be for the coder.  Learn NOT to write programs that
: destroy data without giving feedback.  Learn NOT to write programs that
: don't give feedback.

I completely agree.  However, that doesn't mean Microsoft will pay me if
Word ate my document, does it?  Who gets fired?

: I think a car analogy is good, here.  Every car I've ever owned has come
: with an owner's manual.  I suspect that there isn't a person on the
: face of the earth has ever read one of those.  I suspect that there are
: thousands of mechanics, car dealers, automotive engineers, and suchlike
: who have never read the owner's manual for their automobile.  The thing
: is, a car will give you feedback.  If you pay attention to the vehicle,
: it will let you know when it needs service and you often do not need to
: know the details of how to test the level of power steering fluid.

You're joking, right?  All cars I've driven in have this red line on
the tachometer (if it has a tachometer at all), and *nothing* to prevent
me from accelerating past that line.

Yes, the red line is documented, but what does it mean?  Is it the point
where you should be careful because it's about to break, or is it the
point it actually breaks?  What happens when it breaks?  Does the engine
explode or shut down gracefully?

Now, a grades submission program is not a car.  It's not likely that
people will die from its misuse - not impossible, but not likely.  Its
bugs are something the professor can completely undo (by accepting the
homework).  Surely you don't expect its producer to pour in the kind of
rigor seen in mission-critical systems?

Do we really want to produce CS students who sit on their asses assuming
that software will warn them of every potential problem?

: Computer programs need not obey any physical laws so they cannot, except
: through the effort of the programmer, let the user know what has happend.
: If the program can't tell the user what's going to happen, at least it
: should tell the user what has happened.

All sound principles that I agree with.  However, I'm sure you don't
actually *expect* all software to be this uniformly good.  I'm sure you
don't just sit down in front of a new OS and click and drag randomly and
expect that all damages you make can be undone, right?

: > CS students are people to and deserve good quality software, but 
: > if even *they* don't read the manuals, why bother printing them or 
: > making them available on line?

: Yes, indeed.  Why bother printing them?  I think that the world would
: be a much better place if programmers didn't use the crutch of "the
: manual".  ("The fact that it's going to eat all of your tax records
: and get you sent to jail for the rest of your life if you run it before
: noon on February 29 is documented on page 879 of the manual.  What?
: You didn't commit to memory all 12347 pages of the manual?")

You give some extreme examples.  I believe the more common example is
the idiot who doesn't read at all and breaks something.

Ideally all software would be completely intuitive, requiring no manual.
Is that actually feasible?

[...]