From: mayer@wrc.xerox.com (Jim Mayer)
Newsgroups: comp.lang.lisp
Subject: Re: Why Isn't Lisp a Mainstream Language?
Date: 27 Jan 93 17:25:00 GMT
	<1993Jan19.122952.6942@wavehh.hanse.de> <8261@skye.ed.ac.uk>
Organization: Xerox Webster Research Center

Here are my favorite reasons:

(1) The major Common Lisp implementations that run under Unix are all
monolithic systems.  They are also HUGE.  This means that, as a
practical issue, it is very difficult to write SMALL programs in
common lisp.  Shared libraries, eval servers, and (perhaps) various
extensions to the ANSI block compilation stuff could help but are
either unavailable or surprise prone.

(2) My experience with both Lucid and Franz implementations suggests
that using libraries implemented in other languages (typically "C")
doesn't work very well.  There are several problems:

    (A) The "foreign function" interface needs to be kept up to date.
        Without automatic support this is tedious and error prone.

    (B) There is no way to debug problems in foreign code.

    (C) Wild pointers and array overflows in foreign code break the
        entire system so that NOTHING can be debugged.

    (D) Direct mappings of "C" library calls into foreign calls
        usually yields an interface that is inferior to the native
        interface and "weird" from a Lisp perspective.

    (E) At least until multi-threaded "C" libraries are the norm,
        using non-reentrant libraries from a multi-threaded
        environment is trouble prone.

    (F) Even without threads, a GC that moves objects can cause a lot
        of trouble.

(3) "C++" programming environments are getting a lot of attention, and
are getting pretty good.

(4) Common Lisp I/O is poorly designed for systems tasks and is
typically very slow.  Common Lisp streams suffer from the PASCAL
design flaw that supposes that files can be productively modeled as
big arrays.  Standard Common Lisp streams are not extensible and the
usual CLOSish fix requires a generic dispatch per character or byte.
For fun, compare the overhead of "getc" in "C" with the overhead of a
generic function dispatch and a couple of slot fetches.

(5) There are a lot of libraries and support tools available for "C"
and "C++" programmers.  These include window system support, database
interfaces, numerical computation libraries, parser generators,
lexical analyzers, etc.  If they cannot be used easily and naturally
from Lisp, then any technical advantages that Lisp has will be swamped
by the practical advantages having those libraries available.

(6) I need to be able to share my results with my colleagues.
Given the current lisp implementations, a "C" programmer needs to
switch to a lisp environment in order to use any code that I might
write.  He or she then needs to:

    (A) Buy a lot more memory ($1,000) and some more disk ($1,000).
    (B) Shell out $6,000 to $8,000 dollars for a Lisp development
        environment.

So, having spent $10,000, my collegue gets to:

    (A) Run my code.
    (B) Work in a very, very, inverior "C" development environment.

This puts a real burden on me to write extraordinarily brilliant code.

So.... what (IMHOP) has to be done?

(1) Lisp implementors need to provide compilers that produce standard
object files that can be placed in libraries (both shared and static)
and that can be manipulated by the standard system tools.

(2) The lisp "core" needs to be provided as a shared library so that
"C" programmars can use routines written in lisp by adding no more
than "-llisp" to their "cc" command lines.  The lisp core also needs
to be a lot smaller than it currently is on most unix boxes.

(3) Tools need to be provided to at least partially automate the task
of generating "C" interfaces to lisp code, and lisp interfaces to "C"
code.

(4) A natural mechanism for working with typed "C" pointers in lisp and
lisp pointers in "C" needs to be developed.

*** Flame retardant ****

Please note that I am quite aware that some of the above issues are
technically difficult, especially given the semantics of Common Lisp.
I am explicitly not talking about hows, just about whats.  Furthmore,
my dealings over the years with people at both Franz and Lucid have
been very pleasant and productive.

--
-- Jim Mayer
                                        Phone: (716) 422-9407
Webster Research Center                 Intelnet phone: 8*222-9407
Xerox Corporation                       Internet Email: mayer@wrc.xerox.com
800 Phillips Road, 0128-29E             XNS Email: James L Mayer:Wbst128:xerox
Webster, New York 14580                 Facsimile: (716) 265-7133