earlw@Apple.COM (Earl Wallace) (05/21/89)
My experiences with 'nmake' (from the AT&T ToolChest) indicate a serious problem with "manual pages" in UNIX-land. There seems to be this belief in UNIX-land that all a program needs to be considered "production quality" is a few manual pages. I disagree. This attitude may be fine if the programs are going to be used by people who don't mind spending nights and weekends debugging "production quality" programs and/or "enhancing documenation" to enable these programs to be used by others who might just want to work a normal 60 hour week :-) But for some of us, we just might have a real job that needs to be accomplished and the programs we use should help us to do that job and not hinder us. Gee, if we want to spend money and person-power debugging programs, we would write our own! :-) Think about this: Everyone who bought the $1,??? 'nmake' program will end up spending at least a full 40 hours of their time debugging the code and trying to fill in the holes left by the lack of documenation. Then they can get on with the job of building the "rules" to fit their environment. I should have spent 0 hours debugging the code and should have been able to take the documenation, lay in bed, beach, etc. and read it without having to "try this" and "try that" on the system until I figured out the rules. It's a powerful program, but it's shame that the bugs and documenation make it appear worst than it really is and we all know how long-lasting first impressions can be. The documenation that comes with 'gmake' puts 'nmake' to shame. You get the impression that the GNU folks really want people to use their software. Imagine that! If AT&T wants to make money and have a group of happy customers, it would offer an upgrade to 'nmake', complete with new, and better, documenation with all the bugs fixed. And the word to everyone in UNIX-land who writes these programs: provide good documenation along with your programs and if the program has any value at all, it'll be used instead of a program that does the same thing, but isn't documented as well.
ekrell@hector.UUCP (Eduardo Krell) (05/21/89)
In article <1989@internal.Apple.COM> earlw@Apple.COM (Earl Wallace) writes: >If AT&T wants to make money and have a group of happy customers, it would >offer an upgrade to 'nmake', complete with new, and better, documenation with >all the bugs fixed. As I said before, I don't know whether the new nmake will be offered through the Toolchest or with SVR4, but the bottom line is that it will. Remember, Toolchest programs are totally unsupported. You're expecting too much from something that didn't promise anything. Eduardo Krell AT&T Bell Laboratories, Murray Hill, NJ UUCP: {att,decvax,ucbvax}!ulysses!ekrell Internet: ekrell@ulysses.att.com
earlw@Apple.COM (Earl Wallace) (05/22/89)
In article <11570@ulysses.homer.nj.att.com> ekrell@hector.UUCP (Eduardo Krell) writes: >... >Remember, Toolchest programs are totally unsupported. You're expecting >too much from something that didn't promise anything. >... I agree software is definitely unsupported if it's offered thru the ToolChest. But *support* isn't what I'm concerned about. If the software had good documenation and very few bugs, the user should be able to use it without having to troubleshoot bugs, reading the manual cover to cover 3 times, doing lots of small changes to rules and variables to see what really happens, and still not fully understanding (and trusting) how this software works. The port to A/UX was a simple 'MAKE' and this shouldn't have caused any of my problems. I didn't find anything horrible or unusual about nmake in the bug department (lots of NULL pointers, etc.), but the lack of quality control is quite apparent and disturbing. I can't say that the nmake manual is a lot worse than the standard UNIX manuals, which isn't saying much, eh? But getting 'nmake' up and running in such a way that it could be "trusted" to work as I expected did eat up a hell of a lot more time on my PERT-chart than I projected, and I really don't like taking the heat for project delays for software that gave me the *impression* that it was ready and willing to start work the day it arrived. I didn't see anything in the manual or in the ToolChest that said "If you touch any rule, variable or line of source code, you're in a heap of muck, dude!". Now that I have C-O-M-M-E-N-T-E-D the Makerules.mk file (80% done and learned a lot!), I can say that nmake is really neat and can do just about anything you could ever imagine, but by butt has lots of burn marks on it, you know? In reference to your comment about I'm "expecting too much from something that didn't promise anything", I'm not sure how to reply to this statement. I think I understand that you feel that because the software was offered via the ToolChest, that if it works at all, I shouldn't be complaining. Well, my company shelled out some bucks for this software and if we want our customers to use it, we'll have to cough up another $10K or so, and we'll still have to finish debugging it and improve the manual. The bottom line is, supported or unsupported, it cost us real money and therefore should come with better documenation and less bugs than software that's free, right? If 'nmake' was offered free, I would be much more tolerant about the quality of the software and manual, and would have factored more time in my PERT-chart for the debugging and lack of documenation, but charge me money for it and I do expect higher standards. I'm funny that way :-) I think we need to stop setting our standards so low in the UNIX World, if you write programs and want people to use them, then either go to their desk, sit down and show them how it works, or write a document that they can use, otherwise consider that your program may never be used by anyone unless it's real simple, and you just might have wasted your time writing it.
benson@odi.com (Benson Margulies) (05/22/89)
>As I said before, I don't know whether the new nmake will be offered >through the Toolchest or with SVR4, but the bottom line is that it >will. > >Remember, Toolchest programs are totally unsupported. You're expecting >too much from something that didn't promise anything. > AT&T is expecting about 10 times too much money for the quality. Especially since one is required to spend more than 5K additional on ksh in order to use it. -- Benson I. Margulies
davecb@yunexus.UUCP (David Collier-Brown) (05/22/89)
In article <11570@ulysses.homer.nj.att.com> Eduardo saith: | Remember, Toolchest programs are totally unsupported. You're expecting | too much from something that didn't promise anything. One generally doesn't promise anything for supported programs, either, to avoid being sued. That does not justify an ethical organization like Bell Labs charging money to us to alpha-test software for them. --dave (when I get things free, I expect fair to poor service. when I get them cheap, I expect a little better) c-b
andrew@alice.UUCP (Andrew Hume) (05/22/89)
i haven't read the nmake manual (just the TM and papers) but would offer a criticism of its man page which is nearly twice as long as the Ninth Edition's manual entry for sh(1). This is just too long, even if none of it is superfluous. as for gnu make; it certainly has a splendidly typeset manual although i do miss a manual page (is there one now?). The one thing that most sticks in my mind is that the manual spends several pages covering recursive calls to gnu make and the little conveniences offered fro this while it never actually details the exact mechanism used to determine who is out of date with respect to who. This is not obvious and should be documented as least as well as recursive calls. (I note stu dodged this too but webb miller(?) covered similar ground in SP&E a while back.) make documentation is hard to write, particularly for the more modern makes which have subtle features that interact in nonobvious ways. as for the person who bitched about the toolchest offering several incompatible makes, it is not as if AT&T can't make up its mind (about make). it is simply allowing us (developers buried inside at&t) a chance to let outsiders use our code. this stuff is research, its not supposed to be compatible. if you want a clear consistent view, the best we got is system V. if that is not satisfactory, try toolchest (nmake may be $?,000 but mk is ~$125) or gnu or type in the make from Dr dobbs's journal!
daveh@marob.MASA.COM (Dave Hammond) (05/23/89)
In article <1989@internal.Apple.COM> earlw@Apple.COM (Earl Wallace) writes of his dissatisfaction with the $1000+ `nmake' acquired from the ToolChest (as have so many preceeding him). In article <11570@ulysses.homer.nj.att.com> Eduardo Krell writes: >Remember, Toolchest programs are totally unsupported. You're expecting >too much from something that didn't promise anything. Pardon my intrusion in a thread which I have no firsthand knowledge, however, it seems to me that AT&T has one Hell of alot of nerve selling `totally unsupported' programs which `don't promise anything' for $1000 or more! Now, back to my normal read-only status. -- Dave Hammond daveh@marob.masa.com
smb@ulysses.homer.nj.att.com (Steven M. Bellovin) (05/23/89)
Several people have complained about the quality of nmake and/or its documentation. Nmake is part of the Toolchest precisely because AT&T chose not to make it an official product. This may be smart or stupid -- that's a business call, and I won't try to second-guess it in public. But among the factors that go into such a decision are the costs -- debugging, maintenance, documentation (yes, that costs money (a lot of it) to produce -- etc. It could be that someone decided that the market for nmake was too small to make the investment worthwhile. Another factor is product line compatibility -- as noted by many, nmake is quite incompatible with standard make. That's a serious matter to those who decree what is the One True System V -- and rightly or wrongly, a lot of stuff has been rejected on those grounds.
roy@phri.UUCP (Roy Smith) (05/23/89)
daveh@marob.masa.com (Dave Hammond) writes: > it seems to me that AT&T has one Hell of alot of nerve selling `totally > unsupported' programs which `don't promise anything' for $1000 or more! I never understood this "they have a hell of a neve selling X for $Y" attitude. They can charge whatever they want for software and promise as little support as they like. It's up to you to decide if it's worth it. If you think it's not, nobody's forcing you to buy it. As long as they deliver what they promise (in this case, unsupported source code), I don't see where anybody has any legitimate complaint. -- Roy Smith, System Administrator Public Health Research Institute {allegra,philabs,cmcl2,rutgers,hombre}!phri!roy -or- roy@phri.nyu.edu "The connector is the network"
dyer@spdcc.COM (Steve Dyer) (05/23/89)
In article <11580@ulysses.homer.nj.att.com> smb@ulysses.homer.nj.att.com (Steven M. Bellovin) writes: >Several people have complained about the quality of nmake and/or >its documentation. Nmake is part of the Toolchest precisely because >AT&T chose not to make it an official product. This may be smart >or stupid -- that's a business call, and I won't try to second-guess >it in public. But among the factors that go into such a decision >are the costs -- debugging, maintenance, documentation (yes, that >costs money (a lot of it) to produce -- etc. For God's sakes, if the damn thing were available from the toolchest or from comp.sources.whatever for FREE, we wouldn't be hearing the kind of complaints that we're hearing here. Perhaps instead of complaints you'd be seeing bug fixes freely posted, and maybe we'd all end up with a useful piece of software. Instead, we've got this nether-thing which seems to have all the BAD aspects of proprietary software with none of its advantages. It seems that it's only in the software biz that you can pay $1000 or more and still get something which doesn't work. OK, that's a dangerously naive statement :-) :-). Nonetheless, I don't see why if something isn't worth the $1000, AT&T insists on selling it for that much. -- Steve Dyer dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer dyer@arktouros.mit.edu
gwyn@smoke.BRL.MIL (Doug Gwyn) (05/24/89)
In article <3337@ursa-major.SPDCC.COM> dyer@ursa-major.spdcc.COM (Steve Dyer) writes: >Instead, we've got this nether-thing which seems to have all the BAD >aspects of proprietary software with none of its advantages. Most of the ToolChest products we've obtained have been worth far more to us than what AT&T charged. The advantage is that nifty software like "sam" that everybody should have is made available; if it had to be approved for inclusion in AT&T's grand corporate plan for commercial software licensing first, we'd probably never be able to obtain it. I don't know first-hand whether or not "nmake" has enough problems that it should be withdrawn, price dropped, upgraded, or whatever. You might consider giving the ToolChest administrator your feedback on it.
paul@moncam.co.uk (Paul Hudson) (05/25/89)
In article <11570@ulysses.homer.nj.att.com>, ekrell@hector.UUCP (Eduardo Krell) writes: > Remember, Toolchest programs are totally unsupported. You're expecting > too much from something that didn't promise anything. but that I paid good money for. No wonder legally required software guarantees are called for, when this kind of thing happens. Well that finally decides it. nmake may be the best thing since sliced bread but I will *never* rely on a devleopment tool that comes with no support, and which I can't support myself. I have enough trouble with my own bugs without other peoples bugs irremovably intruding. How a company can get away with charging for a software product they won't support, (even to those prepared to pay for it?), is astounding. It's just another reason to support the FSF. Paul Hudson MAIL: Monotype ADG, Science Park, Cambridge, CB4 4FQ, UK. PHONE: +44 (223) 420018 EMAIL: paul@moncam.co.uk, ;" FAX: +44 (223) 420911 ...!ukc!acorn!moncam!paul `"";";" "/dev/null full: please empty the bit bucket" -- Paul Hudson MAIL: Monotype ADG, Science Park, Cambridge, CB4 4FQ, UK. PHONE: +44 (223) 420018 EMAIL: paul@moncam.co.uk, ;" FAX: +44 (223) 420911 ...!ukc!acorn!moncam!paul `"";";" "/dev/null full: please empty the bit bucket"