home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / lisp / 3410 < prev    next >
Encoding:
Internet Message Format  |  1993-01-28  |  4.9 KB
  1. Path: sparky!uunet!charon.amdahl.com!amdahl!rtech!sgiblab!spool.mu.edu!uwm.edu!biosci!parc!rocksanne!rocksanne!mayer
  2. From: mayer@wrc.xerox.com (Jim Mayer)
  3. Newsgroups: comp.lang.lisp
  4. Subject: Re: Why Isn't Lisp a Mainstream Language?
  5. Message-ID: <MAYER.93Jan27122500@fliff.wrc.xerox.com>
  6. Date: 27 Jan 93 17:25:00 GMT
  7. References: <1993Jan14.055140.5909@alchemy.chem.utoronto.ca> <1jekrqINN339@news.aero.org>
  8.     <1993Jan19.122952.6942@wavehh.hanse.de> <8261@skye.ed.ac.uk>
  9. Sender: news@spectrum.xerox.com
  10. Organization: Xerox Webster Research Center
  11. Lines: 99
  12. In-Reply-To: jeff@aiai.ed.ac.uk's message of 26 Jan 93 19:15:04 GMT
  13.  
  14. Here are my favorite reasons:
  15.  
  16. (1) The major Common Lisp implementations that run under Unix are all
  17. monolithic systems.  They are also HUGE.  This means that, as a
  18. practical issue, it is very difficult to write SMALL programs in
  19. common lisp.  Shared libraries, eval servers, and (perhaps) various
  20. extensions to the ANSI block compilation stuff could help but are
  21. either unavailable or surprise prone.
  22.  
  23. (2) My experience with both Lucid and Franz implementations suggests
  24. that using libraries implemented in other languages (typically "C")
  25. doesn't work very well.  There are several problems:
  26.  
  27.     (A) The "foreign function" interface needs to be kept up to date.
  28.         Without automatic support this is tedious and error prone.
  29.  
  30.     (B) There is no way to debug problems in foreign code.
  31.  
  32.     (C) Wild pointers and array overflows in foreign code break the
  33.         entire system so that NOTHING can be debugged.
  34.  
  35.     (D) Direct mappings of "C" library calls into foreign calls
  36.         usually yields an interface that is inferior to the native
  37.         interface and "weird" from a Lisp perspective.
  38.  
  39.     (E) At least until multi-threaded "C" libraries are the norm,
  40.         using non-reentrant libraries from a multi-threaded
  41.         environment is trouble prone.
  42.  
  43.     (F) Even without threads, a GC that moves objects can cause a lot
  44.         of trouble.
  45.  
  46. (3) "C++" programming environments are getting a lot of attention, and
  47. are getting pretty good.
  48.  
  49. (4) Common Lisp I/O is poorly designed for systems tasks and is
  50. typically very slow.  Common Lisp streams suffer from the PASCAL
  51. design flaw that supposes that files can be productively modeled as
  52. big arrays.  Standard Common Lisp streams are not extensible and the
  53. usual CLOSish fix requires a generic dispatch per character or byte.
  54. For fun, compare the overhead of "getc" in "C" with the overhead of a
  55. generic function dispatch and a couple of slot fetches.
  56.  
  57. (5) There are a lot of libraries and support tools available for "C"
  58. and "C++" programmers.  These include window system support, database
  59. interfaces, numerical computation libraries, parser generators,
  60. lexical analyzers, etc.  If they cannot be used easily and naturally
  61. from Lisp, then any technical advantages that Lisp has will be swamped
  62. by the practical advantages having those libraries available.
  63.  
  64. (6) I need to be able to share my results with my colleagues.
  65. Given the current lisp implementations, a "C" programmer needs to
  66. switch to a lisp environment in order to use any code that I might
  67. write.  He or she then needs to:
  68.  
  69.     (A) Buy a lot more memory ($1,000) and some more disk ($1,000).
  70.     (B) Shell out $6,000 to $8,000 dollars for a Lisp development
  71.         environment.
  72.  
  73. So, having spent $10,000, my collegue gets to:
  74.  
  75.     (A) Run my code.
  76.     (B) Work in a very, very, inverior "C" development environment.
  77.  
  78. This puts a real burden on me to write extraordinarily brilliant code.
  79.  
  80. So.... what (IMHOP) has to be done?
  81.  
  82. (1) Lisp implementors need to provide compilers that produce standard
  83. object files that can be placed in libraries (both shared and static)
  84. and that can be manipulated by the standard system tools.
  85.  
  86. (2) The lisp "core" needs to be provided as a shared library so that
  87. "C" programmars can use routines written in lisp by adding no more
  88. than "-llisp" to their "cc" command lines.  The lisp core also needs
  89. to be a lot smaller than it currently is on most unix boxes.
  90.  
  91. (3) Tools need to be provided to at least partially automate the task
  92. of generating "C" interfaces to lisp code, and lisp interfaces to "C"
  93. code.
  94.  
  95. (4) A natural mechanism for working with typed "C" pointers in lisp and
  96. lisp pointers in "C" needs to be developed.
  97.  
  98. *** Flame retardant ****
  99.  
  100. Please note that I am quite aware that some of the above issues are
  101. technically difficult, especially given the semantics of Common Lisp.
  102. I am explicitly not talking about hows, just about whats.  Furthmore,
  103. my dealings over the years with people at both Franz and Lucid have
  104. been very pleasant and productive.
  105.  
  106. --
  107. -- Jim Mayer
  108.                                         Phone: (716) 422-9407
  109. Webster Research Center                 Intelnet phone: 8*222-9407
  110. Xerox Corporation                       Internet Email: mayer@wrc.xerox.com
  111. 800 Phillips Road, 0128-29E             XNS Email: James L Mayer:Wbst128:xerox
  112. Webster, New York 14580                 Facsimile: (716) 265-7133
  113.