home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / misc / 2813 < prev    next >
Encoding:
Internet Message Format  |  1992-08-30  |  5.7 KB

  1. Path: sparky!uunet!gatech!purdue!mentor.cc.purdue.edu!noose.ecn.purdue.edu!samsung!nighthawk.clearpoint.com!transfer!m2c!jjmhome!smds!rh
  2. From: rh@smds.com (Richard Harter)
  3. Newsgroups: comp.lang.misc
  4. Subject: Re: Indentation
  5. Message-ID: <1992Aug31.014156.9282@smds.com>
  6. Date: 31 Aug 92 01:41:56 GMT
  7. References: <1992Aug23.215627.22233@smds.com> <1992Aug16.045245.9912@smds.com> <7050@charon.cwi.nl> <1992Aug18.065110.20337@smds.com> <id.Q0KS.MS1@ferranti.com> <1992Aug27.201810.20982@usenet.ins.cwru.edu>
  8. Reply-To: rh@ishmael.UUCP (Richard Harter)
  9. Organization: Software Maintenance & Development Systems, Inc.
  10. Lines: 106
  11.  
  12. In article <1992Aug27.201810.20982@usenet.ins.cwru.edu> ah739@cleveland.Freenet.Edu (Leslie J. Somos) writes:
  13. >
  14. >In a previous article, rh@smds.com (Richard Harter) says:
  15. >[...stuff...]
  16. >>Too general.  [This sentence no verb.]  One can distinguish between
  17. >>forcing a choice between essentially equivalent alternatives and the
  18. >>eliminating the alternatives altogether. 
  19.  
  20. >Let's have some more choices than just 2.
  21. >"Anybody who says there are two sides to any question
  22. >suffers from a lack of imagination." -- ?
  23.  
  24. Bah, humbug.  You are making ontological commitments on my behalf that
  25. I do not acknowledge.  The mere fact that I say that I can distinguish
  26. between red and blue does not mean that I am denying the existence of
  27. yellow and green, to say nothing of heliotrope.
  28.  
  29. >>Consider the language FL (short for fascist layout). 
  30. >[...]
  31.  
  32. >OK, I believe most people would agree that choices in program layout are
  33. >just fluff, unimportant (in languages that don't care).
  34.  
  35. >>Now consider the language FVN (short for fascist variable names).
  36.  
  37. >STOP RIGHT THERE.  I, for one, will not agree that choice of variable
  38. >names is not important.  Of course, the compiler doesn't care, about
  39. >names or layout, that's why obfuscating programs work.
  40. >But variable names are _very_ important to humans who must read
  41. >programs.
  42.  
  43. Er, one of us missing the point [assuming that there is one :-)].  In
  44. the deleted original it was assumed that names were drawn from predefined
  45. dictionaries.  Consider the following argument.
  46.  
  47.     The term, computer language, is a misnomer.  When I refer to
  48.     a natural language such as English or French, I am referring
  49.     to the both the grammar and the dictionary.  Except for neologisms
  50.     everyone writing English uses the same words from the same
  51.     dictionary.  When people speak of a computer language they
  52.     specify only the grammar and a handful of words that are
  53.     grammatical terms.
  54.  
  55.     Each program constitutes a language in its own right; the
  56.     declarations in the program are its dictionary.  Programs in
  57.     a "computer language" are actually a family of languages, each
  58.     sharing a common grammar.
  59.  
  60.     Suppose, when we read a book we had to first read the dictionary
  61.     for the book that told us what each word meant.  Suppose that
  62.     we had to write a new dictionary afresh for each book we wrote.
  63.     Not only would literacy plummet, with the vocabulary of each book
  64.     being a major study in its own right, but the quality of the
  65.     vocabularies would suffer, since each author must reinvent the
  66.     English dictionary de novo.
  67.  
  68.     Surely we would consider such a state of affairs to be absurd.
  69.     Yet we accept this state of affairs in computer software
  70.     without question.  Programmer A in program X uses the variable
  71.     fooby; it is an integer signifying the number of chickens in a
  72.     chicken coop.  Programmer B in program Y uses the variable fooby;
  73.     it is a character string in a class instance signifying the
  74.     name of the city dogcatcher.  The term, fooby, means nothing,
  75.     or at best its meaning is a shadow written on the sand.
  76.  
  77.     How much better it would be if I could go from program to
  78.     program and find that the meaning of variable names did not
  79.     change capriciously.  How much better would it be if I, as
  80.     the author of a program, did not have to invent my own mini
  81.     language anew with each new program.
  82.  
  83. >You can have all kinds of constraints on what a compiler will/won't
  84. >accept, or relax them all you want.  From a programmer's point of
  85. >view, the most important audience for a program is a programmer.
  86. >We don't care how hard it is for the compiler to handle it, we
  87. >would like to make it easy to understand a program that we have to
  88. >look at.
  89.  
  90. I think you are assuming that the point of a FVN language is to simplify
  91. life for the compiler writer.  Not at all.  The point is to remove choices
  92. for the programmer that should not have to be made.
  93.  
  94. You might very well argue that a FVN language is not practical, or that
  95. the notion is ill-judged, or that there are compensating advantages in
  96. creating separate notation for each program.  However to simply claim
  97. that names are important to a programmer is to miss the point.
  98.  
  99. I am far from claiming that FVN is the way to go.  However there is much
  100. to be said for it, and obeisance is made to the concept in practice.
  101. Programmers do use standard include files and standard notation.  The
  102. use of idiosyncratic substitutes for standard notation is generally
  103. recognized as creating maintenance problems, regardless of the merits
  104. of the idiosyncratic substitute.
  105.  
  106. When I wrote English prose I do not feel handicapped by having to use
  107. words from the dictionary.  I still have the freedom to choose which
  108. words to use and how to arrange them.  Indeed, the quality of my prose,
  109. such as it is, would suffer immensely if I had to invent my own words
  110. and carefully explain them before I could say anything.  One can at
  111. least entertain the suspicion that the same might be true of computer
  112. programming.
  113. -- 
  114. Richard Harter: SMDS Inc.  Net address: rh@smds.com Phone: 508-369-7398 
  115. US Mail: SMDS Inc., PO Box 555, Concord MA 01742.    Fax: 508-369-8272
  116. In the fields of Hell where the grass grows high
  117. Are the graves of dreams allowed to die.
  118.