Re: Any research putting c above ada?

[Jonathan Guthrie <jguthrie@brokersys.com>]

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.

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.)

> >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 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 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.

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.

> 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?")

Documentation has a use, but it's not to keep users out of trouble.
When a program is about to eat data, it should let the user know.

> Anyway, it is always better to check
> for yourself rather than relying on there not being something fucked 
> up with the software. WARNING: This software only saves your latest
> submission to any project, so if you submit it twice, resubmit the 
> entire project.

Does it give the warning when you save the file?  Why didn't you say
so?  That's different.  If you ignore a well-placed notice that, then
there's nothing you can do to help him.

It might be helpful for you to consider the placarding requirements
for aircraft.  ALL of the information on the placards is in the POH,
(Pilot's Operating Handbook,) shoot, the placards themselves are
documented in the POH.  However, the placards contain information that
is considered important enough to be placed in front of the pilot when
he might need the information rather than relying on the pilot's memory
of the manual.

-- 
Jonathan Guthrie (jguthrie@brokersys.com)
Information Broker Systems   +281-895-8101   http://www.brokersys.com/
12703 Veterans Memorial #106, Houston, TX  77014, USA

We sell Internet access and commercial Web space.  We also are general
network consultants in the greater Houston area.