shebs@utah-cs.UUCP (Stanley Shebs) (11/17/87)
I'm on Poskanzer's side - "first real C program" is not an excuse for shoddy workmanship, nor is "not a hacker". Posting it has the effect of making hundreds of hopeful people do Barlow's debugging for him. By his own admission, he ran it about "a dozen times" before distribution. By contrast, my own program xconq was run hundreds of times under many different conditions before the first release, and the next release will have been run many thousands of times under an even greater variety of conditions. Many bugs did not manifest themselves at first, and would have been a serious headache to fix after release. Even after all the testing, at least three got out anyhow. It is definitely in everybody's interest to discourage the posting of buggy and untested programs. To those who would post anyway, consider that you are publicly advertising your software competence (or lack thereof), and that no number of disclaimers will erase the bad impression left by bad code. stan shebs shebs@cs.utah.edu Obligatory bug report: the choices of terrain characters in conquest are ridiculous. When representing terrain, the weights of character (# pixels on) should be taken into account - for instance, light characters such as . and , could be used for sea, and heavier characters like - and + and ^ for land, and the heaviest like # and @ for features that should stand out, like cities and volcanoes. At present, the screen is incomprehensible.
billw@killer.UUCP (11/18/87)
In article <5116@utah-cs.UUCP> shebs@utah-cs.UUCP (Stanley Shebs) writes: > By his own >admission, he ran it about "a dozen times" before distribution. I restrain myself. Running a full game of conquest can take weeks, Stan... -- Bill Wisner, HASA "A" Division ..{codas,ihnp4}!killer!billw "I don't mind at all.." -- Bourgeois Tagg
jfh@killer.UUCP (11/19/87)
In article <2128@killer.UUCP>, billw@killer.UUCP (Bill Wisner) writes: > In article <5116@utah-cs.UUCP> shebs@utah-cs.UUCP (Stanley Shebs) writes: > > By his own > >admission, he ran it about "a dozen times" before distribution. > > I restrain myself. > > Running a full game of conquest can take weeks, Stan... > Bill Wisner, HASA "A" Division ..{codas,ihnp4}!killer!billw Sometimes people are screaming for a package you have and meantime back at the ranch, your mailbox is full of requests like "Post or mail me a copy" After ten or fifteen of these requests, I like to post just to get the people off of my back. Only thing wrong with posting is it can take some time for r$ to repost the thing back to the net ... - John. -- John F. Haugh II SNAIL: HECI Exploration Co. Inc. UUCP: ...!ihnp4!killer!jfh 11910 Greenville Ave, Suite 600 ...!ihnp4!killer!rpp386!jfh Dallas, TX. 75243 "Don't Have an Oil Well? Then Buy One!" (214) 231-0993
crds@ncoast.UUCP (11/22/87)
I submit the following: ANYONE who is willing to post their source code on this net is welcome by me! Part of the whole reason to have a network such as this is to promote the common development and sharing of ideas, not to go on about how well YOU write programs as compared to your fellow 'guru'. I also suggest that not many pieces of source code which are submitted on this net, let alone, not many programs being SOLD to the public today by companies such as Microsoft, Digital Research, Ashton-Tate, and the likes, are completely bug free!!! I, for one, would rather see buggy code than no code at all. Not long ago I posted a piece of source code which was specifically written for a Charles River Data System computer running UNOS (which is like, but not exactly UNIX). I had no way of testing whether what I wrote was at all useful on a UNIX system, let alone compatable -- I posted it anyhow. Why?? So that others could see my thought processes, look at my code, improve upon it, and push it back my direction in a "higher" form. THIS IS ONE OF THE REASONS I SPEND TIME ON THIS NETWORK. How many of us work well in a vacuum? (with the follow up question) If in fact you DO work well in a vacuum, WHO notices your work until you take it out of the vacuum, and HOW do you test it without putting it into use? I challenge most 'gurus' out there to be effective in finding BUGS in their own programs WITHOUT EVER giving it to a "MONKEY" to beat on it. Sure, SOME of you can, and in fact HAVE done this -- but it's rare that anyone spends the time, let alone has the insight to exercise a program to it's operational limits and beyond. In summary, I suggest this: IF YOU DON'T WANT BUGGY CODE FROM THIS NETWORK, GET OFF THE NETWORK. In the mean time, I'll be just happy to recieve all the buggy code you'd like to send me. Glenn A. Emelko ...cbosgd!mandrill!hal!ncoast!crds
bc@halley.UUCP (Bill Crews) (11/30/87)
In article <5747@ncoast.UUCP> crds@ncoast.UUCP (Glenn A. Emelko) writes: > > In summary, I suggest this: > > IF YOU DON'T WANT BUGGY CODE FROM THIS NETWORK, GET OFF THE NETWORK. > > In the mean time, I'll be just happy to recieve all the buggy code you'd >like to send me. I agree with Glenn in sentiment and almost in totality. The only exception I would take is that the degree of effort just to ensure that the shar file is constructed correctly and make files actually work is really minimal, and the effect that such errors have is to consume *many* times the productivity in discovery than it would take just to double-check the posting. PLEASE: Don't anyone quit posting ANY sources. PLEASE: Just take the couple of minutes it takes to get the posting itself done right. I'll live with the bugs. -bc -- Bill Crews Tandem Computers Austin, Texas ..!rutgers!im4u!esc-bb!halley!bc (512) 244-8350