home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / lisp / 3329 < prev    next >
Encoding:
Text File  |  1993-01-22  |  8.2 KB  |  169 lines

  1. Newsgroups: comp.lang.lisp
  2. Path: sparky!uunet!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!yale!mintaka.lcs.mit.edu!gateway
  3. From: SWM@stony-brook.scrc.symbolics.com (Scott McKay)
  4. Subject: Re: Why Isn't Lisp a Mainstream Language?
  5. Message-ID: <19930122162651.0.SWM@SUMMER.SCRC.Symbolics.COM>
  6. X-Unparseable-Date: Fri
  7. Sender: news@mintaka.lcs.mit.edu
  8. Organization: LCS news/mail gateway
  9. References: <1993Jan21.230642.18561@netlabs.com>
  10. Date: Fri, 22 Jan 1993 16:44:03 GMT
  11. Lines: 156
  12.  
  13.     Date: Thu, 21 Jan 1993 18:06 EST
  14.     From: Larry Wall <lwall@netlabs.com>
  15.  
  16.     In article <19930120191159.1.SWM@SUMMER.SCRC.Symbolics.COM> SWM@stony-brook.scrc.symbolics.com (Scott McKay) writes:
  17.     : I cannot decide if your analogies are false since I cannot make heads
  18.     : or tails of them.
  19.  
  20.     You should try to make CARs and CDRs of them instead.
  21.  
  22. I personally think CAR and CDR could have been flushed from the
  23. language, since FIRST and REST do the exact same thing.  Note, by the
  24. way, that you have picked one of the very few things retained in Common
  25. Lisp for historical purposes.
  26.  
  27.     : In what way is Lisp "bland ... all the way through"?
  28.  
  29.     There's little visual distinctiveness to distinguish mentally
  30.     distinctive constructs.
  31.  
  32. This is simply not a valid criticism.  There is little visual
  33. distinctiveness in English to distinguish mentally distinctive
  34. constructs, and yet you do not fault English.  In fact, one could argue
  35. that "visual distinctiveness" is a principally a matter of typography.
  36.  
  37.     : How does Lisp's expressiveness (which I believe measures "easy to say
  38.     : and understand") "[get] a big yawn"?  Is it because Lisp is so expressive,
  39.     : that it is boring?
  40.  
  41.     No, I'm saying that Lisp is only expressive by one rather cerebral kind
  42.     of measurement, which neglects many human factors related to how we
  43.     think, perceive and talk.  And that this is the primary reason people
  44.     avoid Lisp.
  45.  
  46. This is still a handwave.  You might be right that it is "easy to say
  47. and understand" things in other languages, but I can equally well claim
  48. (with support from others) that it's "easy to say and understand" things
  49. in Lisp as well.  And unlike in most other languages, if something
  50. becomes cumbersome to say in Lisp, you can write a macro to make it easy
  51. to say again.  Since Lisp is it's own meta-language (this is what many
  52. people erroneously refer to as "Lisp not having any syntax"), Lisp
  53. macros are a natural thing for people to write and use.  It would be
  54. wonderful if other languages did as well, but since a truly powerful
  55. macro facility has to, in effect, operate on the syntax tree for a
  56. language form, things get harder.
  57.  
  58. I really think that the burden is still on you to define what you mean
  59. by "expressiveness", and then show how your pet languages meet these
  60. criteria, and how how Lisp does not.
  61.  
  62.     : Are you saying that most other languages, because they are so
  63.     : horrible and so inexpressive, are not boring because they elicit anger
  64.     : and frustration, whereas Lisp does not elicit those emotions?
  65.  
  66.     I don't believe that the absence of boredom implies the presence of
  67.     anger and frustration.  All these states of being are in opposition to
  68.     creative excitement.
  69.  
  70. Yes.  Boredom, anger, and frustration are all in opposition to creative
  71. excitement.  But you didn't answer the question.  I personally get my
  72. creative excitement from trying to solve new problems, not from
  73. successfully cajoling a language into doing what I want it to do.
  74.  
  75.     : Are you saying that you think that the true challenge in programming
  76.     : is the actual struggling with the language, rather than the addressing
  77.     : the deeper issues (such as, what it is you are trying to do)?
  78.  
  79.     I haven't noticed people struggling that much less with Lisp than with
  80.     most other languages.  Admittedly, nroff is a bit tougher, unless
  81.     you're just trying to do text processing...  :-)
  82.  
  83. Perhaps it is the sort of software I do, but I emphatically do notice
  84. people struggling more with most other languages than with Lisp.  Let's
  85. look at memory management, for instance.  In most other languages, such
  86. as C, programmers must confront the issue of memory management head on,
  87. right away, even if they don't want to do memory management.  I'm
  88. willing to simply concede the point that, with a little practice,
  89. "anybody" can write working memory management in C (although not without
  90. first pointing out that, in the past year I've read two papers claiming
  91. that around 40% of a C programmer's time is spent chasing dangling
  92. poiinters and storage leaks).  The point is that, in most other
  93. languages, programmers must immediately tackle programming tasks that
  94. are only incidentally related to the problem at hand.
  95.  
  96.     : In what way does Lisp "push down so hard" on morphology?
  97.  
  98.     One form to rule them all,
  99.     One form to find them,
  100.     One form to bring them all
  101.     And in the darkness bind them.
  102.     In the land of machinery, where the symbols lie.
  103.  
  104.     Essentially, Lisp assumes that humans like to write programs the same
  105.     way the machines like to execute them, and so conflates the human
  106.     representation with the machine representation.  True, there are Lisp
  107.     compilers, but the "ideal" is still that the machine and the programmer
  108.     are interpreting the exact, same, one-size-fits-all data structure.
  109.  
  110. I fail to see that Lisp makes any such assumption.  What machines
  111. directly execute mapping operators?  Reduction operators?  What machines
  112. directly execute generic arithmetic, including integers, large integers,
  113. floating point, and ratios?  Hash tables?  Sequences and collections?
  114. This claim just cannot be made to stick.
  115.  
  116. If I didn't know better, I would be sure that you are talking about C/C++.
  117.  
  118. I also think you have confused what you call "machine representation"
  119. with "parsed representation".  The fact that the human-readable
  120. representation is the same as the basic parsed representation is one of
  121. the great sources of Lisp's power -- it allows Lisp programs to
  122. effortlessly talk about Lisp programs.
  123.  
  124. Perhaps you think that Lisp's "one-size-fits-all data structure" is the
  125. list, but that reflects a circa-1972 bias for the language (or maybe
  126. even earlier).
  127.  
  128.     : Where's the "tar pit", and what languages do better?  (I can think of
  129.     : some languages that do better in some areas, but none that, taken as a
  130.     : whole, do better for most purposes).
  131.  
  132.     That's precisely the point.  "Beware the Turing Tarpit, where
  133.     everything is possible, and nothing is easy."
  134.  
  135. I'll consider myself warned, and avoid Algol-68 as much as possible.
  136.  
  137.     That said, I should back off a little and admit that there are a few
  138.     things that are easier in Lisp than in other languages.  But your
  139.     assumption seems to be that it's better to use an all-around mediocre
  140.     language for most everything than to use each language for what it does
  141.     best.  I'm just pointing out the obvious fact that most people disagree
  142.     with that assumption nowadays, and that I suspect that this is the
  143.     answer to the question posed in the subject line of this thread.
  144.  
  145. I don't claim that Lisp is an all-around mediocre language.  It's an
  146. all-around excellent language.  Sure, there are some languages that have
  147. a few features that are better than what I can find in Lisp, but so
  148. what?  If you just want to do rule-chaining and nothing else, by all
  149. means use Prolog.  If you are writing an interrupt handler for a device,
  150. why not use C or Bliss?  If you are doing program proofs, use ML or
  151. Haskell.  And why not use Fortran for some scientific hacking?  But for
  152. general programming, I'll take Lisp nearly every time.  Moral: use the
  153. right tool for the job.
  154.  
  155. So while you may be pointing out an obvious fact that people don't want
  156. to use an all-around mediocre language, you are just tilting at a windmill,
  157. since I made no such assumption.
  158.  
  159.     : I can't even decide if you are serious or not.  I guess that all of
  160.     : your handwaving means that you must be making a joke.  In that case,
  161.     : I guess I am too dense to get the joke.
  162.  
  163.     Never assume, just because I'm making a joke, that I'm not also quite serious.
  164.  
  165. What makes me sad is that I know you're serious, and yet you have
  166. entirely missed the real issues about why Lisp isn't a mainstream
  167. language.  Other messages (e.g., Pete Halverson's) under the same
  168. subject have started to touch on the real issues.
  169.