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

  1. Path: sparky!uunet!UB.com!pacbell.com!ames!agate!doc.ic.ac.uk!warwick!uknet!edcastle!aiai!jeff
  2. From: jeff@aiai.ed.ac.uk (Jeff Dalton)
  3. Newsgroups: comp.lang.lisp
  4. Subject: Re: Lisp syntax beauty? (was Re: Why Isn't Lisp a Mainstream Language?)
  5. Message-ID: <8283@skye.ed.ac.uk>
  6. Date: 28 Jan 93 19:48:38 GMT
  7. References: <dfs.727732459@kehleyr>> <KRULWICH.93Jan25102251@zowie.ils.nwu.edu> <dfs.727981585@kehleyr>
  8. Sender: news@aiai.ed.ac.uk
  9. Organization: AIAI, University of Edinburgh, Scotland
  10. Lines: 64
  11.  
  12. In article <dfs.727981585@kehleyr> dfs@doe.carleton.ca (David F. Skoll) writes:
  13. >In <KRULWICH.93Jan25102251@zowie.ils.nwu.edu>
  14. >krulwich@zowie.ils.nwu.edu (Bruce Krulwich) writes:
  15. >
  16. >
  17. >>It seems to me that if you mentally think of the language spec as what
  18. >>in other languages would be "language + standard libraries," things
  19. >>make much more sense.  The fact that LISP systems are based on
  20. >>run-time environments and REPL modes makes it hard to provide a good
  21. >>seperation between the two, and in any case from a language definition
  22. >>point of view there's no diffference (unless you want things to be
  23. >>optional, the way scheme does).
  24. >
  25. >I think the paragraph above sums up nicely why Lisp is not a
  26. >mainstream language.  Having to "think" of it as something else is not
  27. >something most programmers want to do.
  28.  
  29. Let me get this straight.  They know the "truth" about Lisp but don't
  30. want to have to think of it some other way?  Suppose we define it as
  31. a language + libraries (as EuLisp does).  Would that make any
  32. difference?
  33.  
  34. >They want a language that's portable, small, standard and cheap. 
  35.  
  36. Scheme.
  37.  
  38. >Common Lisp programs are (in theory) quite portable, but in practice
  39. >are no more portable than C programs.
  40.  
  41. They're more portable in some ways, less in others.  For instance, I
  42. have no trouble porting my CL programs from one machine/OS to another.
  43. I have more trouble going from one CL implementation to another.
  44.  
  45. One thing CL lacks is a standard (or de facto standard) for object
  46. files and libraries, as C does.
  47.  
  48. >  Common Lisp is not small, so it's not that good for small
  49. >applications.
  50.  
  51. Depends, but it's usually so.
  52.  
  53. >  And Lisp is not cheap - if you want to distribute Lisp
  54. >applications, you usually have to pay $$$ to the Lisp vendor to
  55. >distribute Lisp run-time licenses.
  56.  
  57. Most of the Lisps I use are free.  That's right: zero $$$.
  58.  
  59. >Also, the good Common Lisp compilers are not free - are quite expensive,
  60. >in fact.
  61.  
  62. Not so!  CMU CL has an excellent compiler.
  63.  
  64. >Compare this to C, for example, which has no run-time royalties, and
  65. >has a free ANSI-standard compiler.
  66.  
  67. Ok, I compare it, and I find that CL has the same.  As does Scheme.
  68.  
  69. >Another problem is that Lisp enthusiasts are not that good at
  70. >marketing Lisp. :-) When you tell people "well, think of this as..."
  71. >they switch off.  :-)
  72.  
  73. No doubt because their minds are soooo.... open!
  74.  
  75. -- jd
  76.