willc@tekcrl.TEK.COM (Will Clinger) (08/08/88)
In article <3424@phoenix.Princeton.EDU> eliot@phoenix.Princeton.EDU (Eliot Handelman) writes: >I just want to make a practical suggestion to lisp documenters: I think >it makes sense to indicate the existence of EVERYTHING available in the lisp, >in EVERY package, regardless whether or not it's felt that the user has >the right to use these things are not. And considering the volume and expense >of the Lucid doc, I can't see why this was not done. Counterarguments? People who use procedures and variables that are intended to be private to an implementation might get a little upset if the feature they rely upon in Lisp version 7.14 disappears in version 7.15. The documentation could say of such features that they should not be relied upon and that anyone who uses them is crazy, but some people would still interpret the fact that they are documented at all as an implied warranty of stability. Any system that documented such features would be inviting the wrath of its users. It also costs a lot of money to generate pretty, polished documentation that can be distributed to users. For system internals, that money would be better spent on ugly, rough, but more complete internal documentation. The customer would ultimately benefit from greater reliability and more timely enhancements. All things considered, it seems to me that users are much better off when they don't know anything about ephemeral system internals. The fact that they can easily learn about undocumented system quirks by browsing the package system is just one more sign that the package system is not a satisfactory solution for programming-in-the-large. William Clinger Semantic Microsystems, Inc.
ruffwork@orstcs.CS.ORST.EDU (Ritchey Ruff) (08/08/88)
In article <2912@tekcrl.CRL.TEK.COM> willc@tekchips.CRL.TEK.COM (Will Clinger) writes: >In article <3424@phoenix.Princeton.EDU> eliot@phoenix.Princeton.EDU (Eliot Handelman) writes: >>[...] I think >>it makes sense to indicate the existence of EVERYTHING available in the lisp, >>in EVERY package, regardless whether or not it's felt that the user has >>the right to use these things are not. [...] >[...] >All things considered, it seems to me that users are much better off when >they don't know anything about ephemeral system internals. [...] a flame, then lucidity ( ;-) follow. ***flame on*** *IF* a full *layered* interface were provided and fully documented for SYSTEM: (et al, just as it is for USER: now via CLtL) then I would have no gripes, but when you *can't* do things easily (or at all) until you grope around in the packages to find out how to talk to the underlying OS in a particular way, or have to use the foreign function interface and write you own system interface code, or call the hotline and ask then get told "your not suppose to do that!" ; that's when I think the mentality as expressed by Will Clinger gripes me. "Oh, you don't *WANT* to know about those nasty things, just tell us what the problem is and we will fix it, or give you a workaround, or tell you how to do it right, or..." It gives the company lots of chance to make money from supporting products, because without a hotline to cry for help you are in deep yogart many times... ***flame off*** sorry, but I've been hacking common lisp's with poorly documented features (and sometimes the lack of documentation allows a company to claim a bug as a feature---it wasn't documented to act in any given way, so we *claim* it's working right!). I agree with Will that the "typical enduser" should not be privy to this level of detail, but as a developer/researcher I *NEED* to be---if I want to be able to do what I want to at all and have it look nice (and give people who see it good feelings about XYZ's version of CL--- wow, look what they did using *that* version of CL). Developers and researchers often need MUCH more detailed info then the typical *end user* (hmmm, anyone *EVER* ment a typical enduser???). sorry again to flame, but you pressed my button ;-) --ritchey ruff ruffwork@cs.orst.edu -or- ...!tektronix!orstcs!ruffwork