home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / c / 17060 < prev    next >
Encoding:
Internet Message Format  |  1992-11-23  |  3.9 KB
  1. Xref: sparky comp.lang.c:17060 comp.software-eng:4475
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!cs.utexas.edu!sun-barr!olivea!charnel!sifon!homer.cs.mcgill.ca!zaphod
  3. From: zaphod@cs.mcgill.ca (Morris BERNSTEIN)
  4. Newsgroups: comp.lang.c,comp.software-eng
  5. Subject: Re: Will we keep ignoring this productivity issue?
  6. Message-ID: <1992Nov23.212641.22758@cs.mcgill.ca>
  7. Date: 23 Nov 92 21:26:41 GMT
  8. References: <1992Nov17.014638.25391@mole-end.matawan.nj.us> <Bxx865.A4v@cdsmn.mn.org>
  9. Sender: news@cs.mcgill.ca (Netnews Administrator)
  10. Organization: SOCS - Mcgill University, Montreal, Canada
  11. Lines: 69
  12.  
  13. In article <Bxx865.A4v@cdsmn.mn.org> wells@cdsmn.mn.org (Rich Wells) writes:
  14. >mat@mole-end.matawan.nj.us wrote:
  15. >:                                           I'm not saying that a programmer
  16. >: shouldn't understand the architecture of a digital computer, but that such
  17. >: an understanding will be an idealization, whose specifics cannot be applied
  18. >: to any particular hardware, and that it will have vanishing impact on 99%
  19. >: or more of his work.
  20. >
  21. >This may be true for MIS types programming in 4GLs and the like,
  22. >but I find that a knowledge of the particular hardware one is
  23. >programming for is necessary for two reasons: (1) for the few
  24. >times that one needs to resort to assembly language to get the
  25. >needed performance, and (2) for debugging.  I have seen a
  26.                                                    ^not?
  27. >competent debugger who did not have intimate knowledge of the
  28. >hardware she was working on, nor have I ever seen a competent
  29. >programmer who was not also a good debugger.
  30.  
  31. A dissenting opinion is offered (i.e. I strongly agree with mat).
  32. Very few applications need that extra boost from assembly code.
  33. Assembly-language programming is a legitimate area of specialization.
  34. If one has the skill to write good assembly, one should not waste the
  35. talent grinding out the 90+% of code that is routine.  Since the
  36. assembly code is such a small portion of the project, the specialist
  37. can divide his/her energies among several projects.
  38.  
  39. Personally, I would rather use techniques that give me more leverage.
  40. You seem to be sneering at 4GLs.  As a professional, I have designed
  41. and implemented 4GLs (technically, application-domain languages) and
  42. then coded in the 4GL to deliver the application.
  43.  
  44.  
  45. As far as requiring machine-language skill for debugging, that's
  46. ridiculous.  I've had to debug applications across multiple platforms
  47. and I don't have time to learn the intimacies of each one.  In the
  48. past year, I've written and compiled code for Sun-3s, SPARCs, NeXT,
  49. Macs, MIPS (DecSystems) and HP RISCS.  I can't recall the last time I
  50. had to go down to machine level to solve a problem.
  51.  
  52. Debugging happens when the system doesn't work the way it's expected
  53. to work; it just requires some basic problem-solving skills and some
  54. tools.  I have a single question that covers the vast majority of
  55. debugging problems: Is that TV set plugged in?  For the remaining few
  56. cases, you have to be systematic and methodical.  It also helps if you
  57. design the application with debugging in mind.
  58.  
  59.  
  60. >
  61. >(BTW: my opinion here comes from the two areas I work in on a day-
  62. >to-day basis: high-end, high performance photo retouch systems,
  63. >and embedded systems for controlling graphics output devices.  I'm
  64. >always interested in hearing from people in other application
  65. >areas as to how their perceptions on this sort of matter differs
  66. >from mine.)
  67.  
  68. OK.  You picked a particular application area where you do want to
  69. push the envelope.  In your case you do want to squeeze every last
  70. cycle out to the hardware.
  71.  
  72. The systems I've worked on solved different problems.  In my case, if
  73. performance was a problem, we could get faster hardware or tune the
  74. application without resorting to assembler.
  75.  
  76. The thing that concerns me about assembler is that it tends to be less
  77. maintainable and less portable than high-level code.  I need to be
  78. convinced of the need before resorting to it.
  79.  
  80.  
  81. Morris
  82.