dhesi@bsu-cs.UUCP (Rahul Dhesi) (05/18/87)
In article <6570@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes: > In article <34ab3c5c.8be4@apollo.uucp> jps@apollo.uucp [writes]: > [...] > >The attitude seems to be one of "If I can make a funny remark or > >witty comment about the inadequancies of the program, then I don't have > >to make it work." Thats why "FIND" is documented with: > > "BUGS: The syntax is very painfull." > >If they cared, they'd fix it. > > Not so. It is true that the very name `BUGS' is meant in jest; > but while stodgier names include `LIMITATIONS' and `RESTRICTIONS', > the contents of these sections in other systems' manuals are > identical. `Fixing' the syntax of find would be a disservice, for > it is now too well engrained. This is perhaps too late to say this, but which do you trust more: an operating system that frankly lists its numerous bugs/deficiencies, or one that pretends they don't exist, or wants you to believe that they are really special features? As an example, VAX/VMS aborts the following Pascal fragment with a fatal error: var i: integer; begin for i := 1 to 2000 do write ('*'); /* fill screen with 2000 stars */ end; If this is not a bug I would like to know what it is; if it is documented anywhere as a bug I would like to know where. As another example: If you are using a binary file from VMS C, ftell() does not return the current file pointer position, fseek() will not seek to the nth byte of the file, and under certain conditions, a write() of an arbitrary number of bytes will cause an error. Elsewhere, the manual goes on to explain say that these are powerful "features". They ought to have gritted their teeth and come right out and documented these as the bugs that they really are. Lately, AT&T's UNIX has changed. The traditional "BUGS" entry is now frequently "NOTES" or "RESTRICTIONS" and the comment about find's painful syntax seems to be gone from AT&T documentation. Thankfully, BSD still maintains its original blunt philosphy of respecting the user's intelligence and not hiding behind euphemisms. All operating systems have their weaknesses. Some just admit them more freely than others. -- Rahul Dhesi UUCP: {ihnp4,seismo}!{iuvax,pur-ee}!bsu-cs!dhesi
corwin@bsu-cs.UUCP (Paul Frommeyer) (05/18/87)
In article <663@bsu-cs.UUCP>, dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: > This is perhaps too late to say this, but which do you trust more: an > operating system that frankly lists its numerous bugs/deficiencies, or > one that pretends they don't exist, or wants you to believe that they > are really special features? > > As an example, VAX/VMS aborts the following Pascal fragment with a > fatal error: > > var i: integer; > begin > for i := 1 to 2000 do > write ('*'); /* fill screen with 2000 stars */ > end; > > If this is not a bug I would like to know what it is; if it is > documented anywhere as a bug I would like to know where. It is documented as a feature of VAX Pascal; The screen is considered to have fixed length-carriage control. And even better message is had when you try to type a VAX C stream file that's longer than about 256 bytes: %RMS-F-EXCDQUO, disk quota exceeded or some such. Then there's the whole pointer indirection thing in VAX C, which people keep trying to tell myself and Russ was a result of our incompetence, despite two days of studying inch-thick printouts of compiler maps and fighting VAX DEBUG as well... (Yes, we remembered to initiatlize the pointers!) Speaking of which, the VAX DEBUG manual says DEBUG accepts C addressing syntax. But of all the annoying things, EXAMINE/ASCIZ argv[3] will produce a nasty error message when the debugger tries to read the string at the location of the first byte in argv[3] (i.e., location 65 if it's an A, etc.) Then there's the CR/LF suppression with DCL WRITE mentioned in comp.os.vms. The list goes on... > > All operating systems have their weaknesses. Some just admit them > more freely than others. Exactly. And if your operating system acknowledges its faults, its that much easier for the programmer to know what to look for, and the user to understand that its the computer not her that is screwing up. Glossing over major faults and fatal design flaws does not remove the design flaws, it only makes the company doing it appear self-righteous. Carried far enough, this would probably result in some ungodly horror like 1960s computer technology evolving into and industry standard because a company refused to admit there should be some end to upward compatibility... And then there's the joke: The serious design flaws of VAX/VMS are completely hidden by the superficial design flaws, such that suprise and delight at getting the system to do anything at all totally masks the fact that what you just did is inherently useless. As opposed to MVS, which is a serious design flaw. :-) -- Paul "Corwin" Frommeyer "Experience is no substitute for competence." UUCP: {seismo,ihnp4}!{iuvax,pur-ee}!bsu-cs!corwin