home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / c / 16621 < prev    next >
Encoding:
Internet Message Format  |  1992-11-17  |  2.7 KB
  1. Xref: sparky comp.lang.c:16621 comp.software-eng:4332
  2. Newsgroups: comp.lang.c,comp.software-eng
  3. Path: sparky!uunet!tcsi.com!hermes!miket
  4. From: miket@hermes.tcs.com (Michael Turner nmscore Assoc.)
  5. Subject: Re: Will we keep ignoring this productivity issue?
  6. Message-ID: <1992Nov17.003350.2649@tcsi.com>
  7. Sender: news@tcsi.com
  8. Organization: Teknekron Communications Inc.
  9. References: <1992Nov11.055130@eklektix.com> <1992Nov13.062945.425@thunder.mcrcim.mcgill.edu> <BxnpJL.BvM@cs.uiuc.edu>
  10. Date: Tue, 17 Nov 1992 00:33:50 GMT
  11. Lines: 44
  12.  
  13. In article <BxnpJL.BvM@cs.uiuc.edu> johnson@cs.uiuc.edu (Ralph Johnson) writes:
  14. >mouse@thunder.mcrcim.mcgill.edu (der Mouse) writes:
  15. >
  16. >>But from what I can tell, high-level hacking is
  17. >>not something that can be put into words, never mind analyzed
  18. >>reductionistically.
  19. >
  20. >[disagreement registered, much deleted here.]
  21. >
  22. >Studies of expert programmers have shown that knowledge is not
  23. >organized around syntax, but in larger conceptual structures, such as
  24. >algorithms and data structures [Adelson and Soloway].  Soloway
  25. >claims that expert programmers organize their knowledge in plans
  26. >that indicate the steps necessary to fulfill a particular goal
  27. >[Soloway and Ehrlich].   In the same way, it is likely that good
  28. >designers do not think about the notation they are using for 
  29. >recording the design as much as they are looking for patterns that
  30. >they can match against design plans that they have learned in the
  31. >past.  Recognizing and teaching these design plans is therefore
  32. >necessary to produce good designers, but we don't do it.
  33.  
  34. This description, to a great extent, covers almost any kind of
  35. expertise.  Great chess players aren't, like chess computers, ultra-
  36. fast lookahead machines.  Rather, they are excellent pattern-matchers
  37. with highly trained memories.  Design notations are sort of the
  38. chess-sets of good programmers.  "Ah, do I know how to play this
  39. variation?  Can I turn it into such a variation?"  I don't think
  40. that Richard Stallman slackened his pace much in moving from LISP
  41. to C (though he might have slowed down for other reasons.)  Language
  42. differences are, at best, the difference between using your hand
  43. and using a joystick to control a robot hand for moving the chess
  44. pieces.  Patience permitting, the better player will still win
  45. the game.
  46.  
  47. This still begs the question of whether high programmer productivity is
  48. something that can be taught.  How you get to where you get in something
  49. like programming is very much a function of how much you love it.
  50. As with many areas of expertise, there is no shortage of people who
  51. are in love with the image of themselves as superior programmers.
  52. But how many really live for the game itself?  Those, I think, are
  53. the superprogrammers.  Can love of programming be taught?
  54. ---
  55. Michael Turner
  56. miket@tcs.com
  57.