home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / c / 16754 < prev    next >
Encoding:
Internet Message Format  |  1992-11-18  |  2.6 KB
  1. Xref: sparky comp.lang.c:16754 comp.software-eng:4384
  2. Newsgroups: comp.lang.c,comp.software-eng
  3. Path: sparky!uunet!charon.amdahl.com!pacbell.com!sgiblab!sdd.hp.com!usc!sol.ctr.columbia.edu!The-Star.honeywell.com!umn.edu!mmm.serc.3m.com!pwcs!cdsmn!wells
  4. From: wells@cdsmn.mn.org (Rich Wells)
  5. Subject: Re: Will we keep ignoring this productivity issue?
  6. Message-ID: <Bxx865.A4v@cdsmn.mn.org>
  7. Organization: Dicomed, Inc
  8. X-Newsreader: TIN [version 1.1 PL6]
  9. References: <1992Nov17.014638.25391@mole-end.matawan.nj.us>
  10. Date: Wed, 18 Nov 1992 16:51:40 GMT
  11. Lines: 45
  12.  
  13. mat@mole-end.matawan.nj.us wrote:
  14. : 
  15. : What the average programmer needs to know first is how to formulate a
  16. : problem so that it is amenable to computer solution over the long term.
  17. : This demands a simple, powerful theory that can directly abstract what is
  18. : needed from the `physical' description.
  19.  
  20. So far, I agree.
  21.  
  22. :                                           I'm not saying that a programmer
  23. : shouldn't understand the architecture of a digital computer, but that such
  24. : an understanding will be an idealization, whose specifics cannot be applied
  25. : to any particular hardware, and that it will have vanishing impact on 99%
  26. : or more of his work.
  27.  
  28. This may be true for MIS types programming in 4GLs and the like,
  29. but I find that a knowledge of the particular hardware one is
  30. programming for is necessary for two reasons: (1) for the few
  31. times that one needs to resort to assembly language to get the
  32. needed performance, and (2) for debugging.  I have seen a
  33. competent debugger who did not have intimate knowledge of the
  34. hardware she was working on, nor have I ever seen a competent
  35. programmer who was not also a good debugger.
  36.  
  37. (BTW: my opinion here comes from the two areas I work in on a day-
  38. to-day basis: high-end, high performance photo retouch systems,
  39. and embedded systems for controlling graphics output devices.  I'm
  40. always interested in hearing from people in other application
  41. areas as to how their perceptions on this sort of matter differs
  42. from mine.)
  43.  
  44. :                    His vital skills are in applying the tools he is given
  45. : to a problem, and to do that he must have a theory which provides him a
  46. : penetrating understanding of the problem.
  47.  
  48. I'm not sure I understand this statement.  Could you clarify it
  49. a little?  I'm not sure if you're talking about a general theory
  50. of hardware, in which case I would argue that such a general
  51. theory must be supplemented by a knowledge of the particular
  52. h/w one is working with, or the basic theory behind the application
  53. area, in which case the comment is a non-sequitur with which I
  54. agree whole-heartedly.
  55. -- 
  56.  
  57. Richard Wells  wells@cdsmn.mn.org  or  ...!tcnet!cdsmn!wells
  58.