From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_40 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 1014db,1042f393323e22da X-Google-Attributes: gid1014db,public X-Google-Thread: 109fba,1042f393323e22da X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,1042f393323e22da X-Google-Attributes: gid103376,public From: Jonathan Guthrie Subject: Re: Any research putting c above ada? Date: 1997/05/14 Message-ID: <5lbcho$hkv$1@news.hal-pc.org> X-Deja-AN: 241398963 References: <5ih6i9$oct$1@waldorf.csc.calpoly.edu> <5iri6b$jn0@bcrkh13.bnr.ca> <5k60au$gig@bcrkh13.bnr.ca> <5k88f8$387@bcrkh13.bnr.ca> <5ku5tj$9d9$1@goanna.cs.rmit.edu.au> <5AB7287E9247441B.B61EDFD34B8F49B0.FCD25A82E03921C6@library-proxy.airnews.net> <0313A6944836C48E.193DB760B2AB7789.7A79EA9ECF40F6E3@library-proxy.airnews.net> <5lb2mi$3i2@mtinsc03.worldnet.att.net> Organization: Houston Area League of PC Users Newsgroups: comp.lang.c++,comp.lang.c,comp.lang.ada Date: 1997-05-14T00:00:00+00:00 List-Id: In comp.lang.ada Craig Franck 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.