home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / lisp / 3395 < prev    next >
Encoding:
Text File  |  1993-01-28  |  4.4 KB  |  93 lines
  1. Newsgroups: comp.lang.lisp
  2. Path: sparky!uunet!UB.com!pacbell.com!ames!agate!linus!linus.mitre.org!boole.mitre.org!crawford
  3. From: crawford@boole.mitre.org (Randy Crawford)
  4. Subject: Re: Lisp vs English (was Re: Why Isn't Lisp a Mainstream Language?)
  5. Message-ID: <1993Jan27.055532.4556@linus.mitre.org>
  6. Sender: news@linus.mitre.org (News Service)
  7. Nntp-Posting-Host: boole.mitre.org
  8. Organization: The MITRE Corporation, McLean, VA
  9. References: <19930122162651.0.SWM@SUMMER.SCRC.Symbolics.COM> <1993Jan23.073029.29713@linus.mitre.org> <1993Jan27.000253.28545@linus.mitre.org>
  10. Date: Wed, 27 Jan 1993 05:55:32 GMT
  11. Lines: 80
  12.  
  13. In article <1993Jan27.000253.28545@linus.mitre.org> john@thelonius.mitre.org (John D. Burger) writes:
  14. >Randy Crawford (crawford@boole.mitre.org writes:
  15. >
  16. >  Not only is english an unstructured language (as compared with programming
  17. >  languages) ...
  18. >
  19. >Well, any grammar for English would be far larger and more complex than for any
  20. >programming language (except maybe CommonLisp :), but I don't think I'd call
  21. >English unstructured.
  22.  
  23. `The horse ran through the barn, fell.'  No, English isn't entirely unstruct-
  24. ured or else it'd be unintelligible.  But the number of irregularities and
  25. contextual dependencies makes it at least context sensitive, and fully 
  26. unrestricted as far as I'm concerned.  That's pretty unstructured when 
  27. compared to CFG programming languages.  (I refuse to consider English as 
  28. structured but complex.  It's too much a product of messy evolution to claim 
  29. that.)
  30.  
  31. If it isn't relatively unstructured then it's relatively structured.  There-
  32. fore it ought to be relatively easy to specify rules for parsing it.  Yet 
  33. that's shown itself to be *highly intractable*.  So I consider English to be 
  34. comparatively unstructured.
  35.  
  36. So there.  I've run rings around you logically.
  37.  
  38. >
  39. >  Without punctuation and semantic context, it's trivial to write correct english
  40. >  which is effectively illegible; that's illegible to man _or_ machine.
  41. >
  42. >You must make a distinction between syntactic correctness and understanding.  I'm
  43. >not sure which you mean by "illegible", but if I can't parse your trivially
  44. >written sentence, and few other English speakers can either, then it ain't
  45. >English, by definition.
  46.  
  47. So that's the definition of English.  I always wondered.  :-]
  48.  
  49. `The girl saw the boy on the hill with a telescope.'  Legal English.  Trivial.
  50. I can think of at least four ways to parse this.  By your definition, I'm 
  51. illiterate because I can't parse this.
  52.  
  53. I prefer to think that your definition of English is flawed.
  54.  
  55. >
  56. >On the other hand, maybe you meant "understand-ability"; you're correct in that
  57. >it's easy to construct syntactically valid English sentences that I can't
  58. >understand, but that's true for programming languages as well.  I submit that the
  59. >C code for the phone system is not understandable "to man _or_ machine".  It's
  60. >EXECUTABLE, but so what?  Very little code is understandable, as in "what does
  61. >this do, in all circumstances", to machine.  Witness all the research on program
  62. >verification.
  63.  
  64. This is getting more philosophical than I intended.  
  65.  
  66. The only compiler for English is a human.  If the person can't figure out the 
  67. sentence, then it's useless.  Programming languages are equally useless if 
  68. _their_ compilers can't make sense of them.  If the programming language 
  69. source is unreadable to humans, then the programmer has written machine code.
  70. Since nobody is lining up to program in hexadecimal these days, I have to 
  71. conclude that source readability is the reason.  Ergo source code legibility 
  72. is important, whether it completely and correctly describes its intentions or 
  73. not.
  74.  
  75. If in fact Lisp is less legible than other programming languages, then that's
  76. a justifiable black mark against Lisp.
  77.  
  78. >
  79. >Of course, none of this distinguishes Lisp from any other programming language,
  80. >but I just wanted to suggest that as far as "legibility" (which I read as
  81. >"understand-ability") is concerned, natural and programming languages are perhaps
  82. >not that different.
  83.  
  84. But they're not exactly equivalent either since no machine in the world is
  85. capable of making sense of varied natural language.  I hope the same isn't
  86. true of your favorite programming language or you're going to need an 
  87. excellent memory to recall what all your code was originally meant to do.
  88. -- 
  89.  
  90. | Randy Crawford        crawford@mitre.org        The MITRE Corporation
  91. |                                                 7525 Colshire Dr., MS Z421
  92. | N=1 -> P=NP           703 883-7940              McLean, VA  22102
  93.