home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / rec / games / mud / misc / 1737 < prev    next >
Encoding:
Text File  |  1992-12-26  |  2.6 KB  |  53 lines
  1. Newsgroups: rec.games.mud.misc
  2. Path: sparky!uunet!wupost!psuvax1!atlantis.psu.edu!handel!stine
  3. From: stine@handel.psu.edu (Jeffrey Stine)
  4. Subject: Re: Note to any fellow DikuMUD coders...
  5. Message-ID: <m#z1H6r1ob@atlantis.psu.edu>
  6. Sender: news@atlantis.psu.edu (Usenet)
  7. Organization: Penn State University
  8. References: <9212260257.AA22918@TIS.COM> <kwt1H$1cnb@atlantis.psu.edu> <9212261801.AA05796@TIS.COM>
  9. Date: Sun, 27 Dec 92 03:15:05 GMT
  10. Lines: 41
  11.  
  12. In article <9212261801.AA05796@TIS.COM> mjr@TIS.COM writes:
  13. >
  14. [...(much interesting and belated stuff removed)]
  15. >>libc, that is your stupid idea.  The people we are talking about writing
  16. >>this probably would have no clue as to what to do in the case that
  17. >>the library routine they wished to use was "broken". 
  18. >
  19. >    Now who's on his high horse. ;)
  20.  
  21.  Not myself.  Although it is true I don't have much patience for people
  22. that don't know where to begin and without trying ask a bunch of questions;
  23. I take it in stride and only offer something when I have something useful
  24. to say.  Had you gone to the lengths you finally went to without being
  25. goaded there wouldn't be a problem and a few people that could have used
  26. the info would have benefited.  There isn't much to be gleaned from:
  27. "what is this vomit"
  28.  As you say they are your opinions and they ceratinly have merit now
  29. that I know the basis for them.  Unexpressed reasons why you have have
  30. such opinions have no merit however.
  31.  One last thing I would add though in `defense' of my opinion that it
  32. was ok.  The importance of mud code is questionable in my eyes and unless
  33. you are a professional programmer, developing good programming practice
  34.  - in as much as providing portability and avoiding "time bombs" goes -
  35. is not of great interest in this group.  I personally would be careful
  36. of advocating a certain programming style in this environment where most
  37. people are a lot more concerned if it will work _now_. (Though I would
  38. like to see more well thought out code being used to improve the stature
  39. of muds)
  40.  As I usually am, I was mainly being the devil's advocate :) , and
  41. certainly don't suggest that "make do" programming is better than
  42. the alternatives you have offered.
  43.  
  44. P.S. the problem with the inet_nota() in SunOS (4.1.1) I refered to is
  45. no doubt local. It is nonetheless broken. Also the suggestion that
  46. the struct sockaddr_in may one day be changed resulting in problems
  47. is a risk that would affect a great deal of code and has little likelyhood
  48. in happening (More likely the the struct in_addr would be changed) and
  49. the person was using struct sockaddr anyway ;)
  50.  
  51. P.P.S. obsolete code is what keeps programmers working. ;)
  52.  
  53.