home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / software / 5023 < prev    next >
Encoding:
Text File  |  1992-12-16  |  4.4 KB  |  96 lines
  1. Newsgroups: comp.software-eng
  2. Path: sparky!uunet!spool.mu.edu!umn.edu!csus.edu!netcom.com!mcgregor
  3. From: mcgregor@netcom.com (Scott Mcgregor)
  4. Subject: Re: C code Layout
  5. Message-ID: <1992Dec17.012650.23387@netcom.com>
  6. Keywords: C code layout
  7. Organization: Netcom - Online Communication Services (408 241-9760 guest)
  8. References: <1992Dec12.122453.8582@seq.uncwil.edu> <1992Dec15.160408.7367@datascope.com>
  9. Date: Thu, 17 Dec 1992 01:26:50 GMT
  10. Lines: 84
  11.  
  12. In article <MARTINC.92Dec16111734@hatteras.cs.unc.edu> martinc@hatteras.cs.unc.edu (Charles R. Martin) writes:
  13.  
  14. >get tools that suit the job rather than perverting the work to suit the
  15. >tool.  Doesn't that apply to 25-character screens as well?
  16. >
  17. >I'm actually serious -- an acquaintance seriously noted that getting
  18. >full-page screens for their terminals improve productivity substantially
  19. >on a big project, just because it allowed holding a whole function in
  20. >one screenful.
  21.  
  22. Indeed it does apply to these other issues.  It also applies to
  23. whether our programming languages should use color and fonts to give
  24. us additional degrees of freedom to convey more information in the
  25. same visual area.  It argues not just for full page screens, but for
  26. larger displays and even large desktops and tables and whiteboards in
  27. programmer's offices. 
  28.  
  29. Clearly this stream takes the syntax of a language, C in this case, as
  30. a given.  Should we do this so quickly? What might result from other
  31. changes to the language (such as fonts and text styles--literate
  32. programming style, or schematic representations). Is a macro that
  33. compresses 24 lines into one small statement good or bad? etc.
  34.  
  35. Even assuming that we want C as ONE representation, do we want it to
  36. be the ONLY one?  Or might we benefit like architects by being able to
  37. see several equivalent but visually distinct representations. I think
  38. we might. Here's a short description of a past experience that
  39. suggests it might:
  40.  
  41. About two years ago I was managing a team of developers working on a
  42. complex object oriented system of over one million lines, written in
  43. C (not C++, that's a different story). A few subroutines and macros
  44. provided the basic object message dispatching, but coding the messages
  45. in this way was very "long winded", and even simple programs to check
  46. files out of the repository, edit them and check them back in took
  47. over 25 pages. 
  48.  
  49. One of my engineers, Joshua Levy, came up with an innovative way to
  50. read these object message, method and instance variable definitions
  51. and turn them into schematic representations. These schematic
  52. representations were relatively more compact (especially, they used
  53. the horizontal axis more effectively) in many cases, and the
  54. cognitive overhead of understanding them was often much less.  This
  55. allowed programmers to often get an instant understanding of
  56. situations that before had appeared very complex. We even identified a
  57. few old, long standing bugs in the C code, that screamed out at us in
  58. the schematic representation. One was so glaring that we thought we
  59. had a problem in our schematic generator, since the programmer who
  60. wrote the strange looking code claimed that the implications of the
  61. code were impossible and not even worth a first glance. The second
  62. glance showed that "the impossible" had indeed happened. We later
  63. worked on a program that went the other way, converting the schematic
  64. into the equivalent C code.  (It is hard to describe the scehcmatic
  65. form here where I can't draw pictures, but people who have seen
  66. TGS's ProGraph will have a clue).  One obvious lesson from this is
  67. that two llanguage representations can be mathematically equivalent
  68. but from a cognitive performance view very different.
  69.  
  70. Nathaniel Borenstein wrote a book called "Programming as if People
  71. Mattered", which is an expression that I have been using for years.
  72. For reasons I can't explain, we often seem to forget that we
  73. programmers are people too, and subject to the same cognitive
  74. limitations as other people.  Just as ignoring people factors can lead
  75. to disaster in our products, our failure to pay attention to this
  76. issue as it applies to ourselves causes great damage as well.
  77.  
  78.  
  79.  
  80.  
  81.  
  82.  
  83. -- 
  84.  
  85. Scott L. McGregor        mcgregor@netcom.com
  86. President            tel: 408-985-1824
  87. Prescient Software, Inc.    fax: 408-985-1936
  88. 3494 Yuba Avenue
  89. San Jose, CA 95117-2967
  90.  
  91. Prescient Software sells Merge Ahead, the tool for Merging Text or Code and
  92. offers consulting  & training in project management and design for usability.
  93.  
  94.  
  95.  
  96.