home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / lisp / 3398 < prev    next >
Encoding:
Internet Message Format  |  1993-01-28  |  6.7 KB

  1. Path: sparky!uunet!news.univie.ac.at!scsing.switch.ch!univ-lyon1.fr!ghost.dsi.unimi.it!rpi!uwm.edu!spool.mu.edu!agate!doc.ic.ac.uk!uknet!edcastle!aiai!jeff
  2. From: jeff@aiai.ed.ac.uk (Jeff Dalton)
  3. Newsgroups: comp.lang.lisp
  4. Subject: Re: Why Isn't Lisp a Mainstream Language?
  5. Message-ID: <8272@skye.ed.ac.uk>
  6. Date: 27 Jan 93 15:20:55 GMT
  7. References: <1993Jan21.230642.18561@netlabs.com> <19930122162651.0.SWM@SUMMER.SCRC.Symbolics.COM> <1993Jan23.073029.29713@linus.mitre.org>
  8. Sender: news@aiai.ed.ac.uk
  9. Organization: AIAI, University of Edinburgh, Scotland
  10. Lines: 129
  11.  
  12. In article <1993Jan23.073029.29713@linus.mitre.org> crawford@boole.mitre.org (Randy Crawford) writes:
  13. >
  14. >Far be it for me to speak for Larry, but I've been reading this thread
  15. >long enough to see that the other side of the story isn't being told.
  16.  
  17. Really?  Perhaps this time, but the case against Lisp syntax is told
  18. again and again, in my experience.
  19.  
  20. I'd like you to ask yourself something.  How could _anyone_ (who wasn't
  21. a complete idiot) possibly think Lisp was _easier_ to read than other
  22. languages?  Could it be that maybe, for them, it really is easier,
  23. and that they aren't just confused or in the grip of "what they're
  24. used to"?  
  25.  
  26. Just what do you think the story is here?  What's wrong with these
  27. people, in your opinion?  
  28.  
  29. >In article <19930122162651.0.SWM@SUMMER.SCRC.Symbolics.COM> SWM@stony-brook.scrc.symbolics.com (Scott McKay) writes:
  30. >>    Date: Thu, 21 Jan 1993 18:06 EST
  31. >>    From: Larry Wall <lwall@netlabs.com>
  32. >>
  33. >>    : In what way is Lisp "bland ... all the way through"?
  34. >>
  35. >>    There's little visual distinctiveness to distinguish mentally
  36. >>    distinctive constructs.
  37.  
  38. As compared to ... what?  For instance?  Let's have some examples of
  39. this visual distinctiveness.  Let's have it compared to Lisp as
  40. presented in Algol-ish style (ie, different fonts for different
  41. things, as in some of the Scheme texts), or whatever.
  42.  
  43. >                       There's little debate that unindented Lisp is 
  44. >just as hard to read as unindented C, but few of us write unindented C, 
  45. >and ALL Lisp is partly unindented any time two parens are adjacent.
  46.  
  47. What?  All languages are partly unindented every time two visible
  48. characters appear on the same line, no?  What exactly is the problem
  49. in Lisp that you're referring to?
  50.  
  51. In properly indented Lisp, it isn't necessary to pay attention to
  52. individual parens when reading the code.  Even the general structure
  53. of parens is largely redundant, serving chiefly to reinforce the
  54. impression created by the indentation and our knowledge of the
  55. operators involved.  Programmers new to Lisp often try to make it
  56. more readable by putting individual close-parens along on a line
  57. (like they might with an "end" in Algol or a "}" in C).  This
  58. generally makes it _less_ readable.
  59.  
  60. >However I think the real case to be made for Lisp's relative illegibility 
  61. >is one of procedural languages vs. functional languages.  When a process is
  62. >decomposed into separate tasks which are presented sequentially, the reader
  63. >has the least work to do in understanding the intent of the programmer.
  64.  
  65. Do you think functional languages such as ML or Haskell have this
  66. problem?
  67.  
  68. Now, it's true that sequential is often easier to understand;
  69. and that's one reason why Lisp programmers often write things
  70. out sequentially.  On the other hand, nested function calls
  71. are used in almost every language.  Lisp programmers are probably
  72. used to a bit more complexity here than, say, C programmers;
  73. but in well-written Lisp programs procedure definitions tend
  74. to be fairly short, and the complexity of individual expressions
  75. is kept under control.
  76.  
  77. Moreover, sequential isn't always easier to understand, which
  78. is why we don't break every expression down into single steps
  79. in (virtually) any language.
  80.  
  81. >The other perspective is one of general expressibility:  does Lisp succeed
  82. >where other languages fail in producing readable source code and efficient 
  83. >executables, leading to maintainability, modularity, and extensibility?
  84. >To answer this, Lisp must be compared on its own merits, without CLOS or
  85. >Genera. 
  86.  
  87. CLOS is part of Common Lisp.  Let's deal with actual Lisps, please,
  88. such as Common Lisp, Scheme, EuLisp, and Dylan, and not with an
  89. abstract "Lisp".  Common Lisp, EuLisp, and Dylan all have object
  90. systems as part of the language.  EuLisp and Dylan were designed 
  91. post-CLOS, and their object-oriented aspects are not extensions
  92. even historically.
  93.  
  94. >When stripped of its extensions and superb development environment,
  95. >Lisp doesn't appear to me to have a clear upper hand over a language like
  96. >Modula 2 or even Ada, not in any general sense. 
  97.  
  98. I might even agree with that as a general point, though I don't think
  99. Modula 2 or Ada are very good examples.  Indeed, I usually try to say
  100. that some people (like me) find Lisp better (at least for a wide range
  101. of tasks) and that there's more than one good kind of language.  I
  102. think Lisp is _a_ good language, but not the only one; and I don't
  103. expect everyone to prefer the same kind of language.  
  104.  
  105. Where I disagree is when people seem to be saying that Lisp is worse
  106. than other languages.  I don't think that is so, in general, though it
  107. often is so for certain specific purposes.
  108.  
  109. >Prefix notation and functional expressions are two `gotos considered good'
  110. >in Lisp.  Violating either of these will either shut down your equations
  111. >or excommunicate yourself from the Brotherhood.  They're both proscriptive.
  112.  
  113. To me, your entire argument more or less boils down to this: prefix
  114. notation and functional expressions are bad.  There's obviously
  115. something to be said for this.  However, for me and a number of other
  116. people, it turns out that, all things considered, Lisp is more readable
  117. than other languages.  So either prefix notation and functional
  118. expressions aren't as big a problem as some think, or else there
  119. are compensating advantages.  Because I just don't think we're that
  120. different from everyone else.
  121.  
  122. This is not to say that everyone ought to see things our way.  Nor am
  123. I saying that it's entirely a matter of opinion or personal preference.
  124. I think it's like this: when the alternatives in question are sufficiently
  125. good, then it's not wrong to pick any of them.  At this point, it's
  126. individual factors that decide, and it has to be that way, because
  127. there isn't One True Answer.
  128.  
  129. >Lisp isn't the most legible language, nor the fastest in execution, nor the
  130. >smallest in executables, nor the most portable among OSes, nor the easiest 
  131. >to integrate with 3rd party applications.  These are all excellent reasons 
  132. >to prefer other languages when these considerations outweigh Lisp's
  133. >comparative strengths in rapid prototyping, implementation sbstraction, 
  134. >flexible data structures, and run-time flexibility.  [...]
  135.  
  136. >THAT'S why Lisp isn't a mainstream language.
  137.  
  138. What are these mainstream languages, anyway?  C, and what else?
  139.  
  140. -- jd
  141.