Richard Gabriel, CTO of Lucid Inc., reviewed the current state of
LISP in the June issue of AI Expert. Particularly fascinating is
his discussion of LISP's debilitating insistence on doing the
fundamentals right the first time, vs. the success of UNIX and C
through implementation efficiency at the expense of correctness,
completeness, and interface simplicity. Richard concludes that
worse is better: an easy-to-implement system that spreads like a
virus will achieve critical programmer mass and can be [almost]
fixed later; a hard-to-implement, resource-hungry, easy-to-use-if-
you-know-what-you're-doing system like LISP will not be
competitive.

Richard also comments on the psychology of software
development with these languages. C is weak, so programmers write
library routines that provide the next level of robust
functionality. (Services like embedding a system call in a loop
until it succeeds or returns a fatal error code.) This leads
to a tradition of modular programming and code reuse -- but with
a tolerance for idiosyncratic interfaces and incomplete
functionality. LISP programs tend to start with functional
design, then implementation design, then implementation. The
result is essentially correct, but is large, complex, and
delivered late. (Scheme code is more likely to be correct and
small, but monolithic, even later, and slow.)

Richard then lists weaknesses of LISP environments, which
haven't changed much in the last ten years. They are not well
integrated, have no persistence except for files, discourage
multilingual code integration, ignore life-cycle considerations
(documentation, specifications, maintenance, testing, validation,
modification, and customer support), provide insufficient
information access (e.g., for performance monitoring), are too
complex for easy learning and use, and do not support multiple
users.

He still believes that C is wrong for AI, and that we have
to support Common LISP because it's the only available standard.
For the future, he would like to see multilingual development
environments supporting a kernel-based LISP system. The kernel
would resemble Scheme plus modules and macros, minus continuations
and dynamic redefinition of functions. A linguistic layer would
flesh out the language and a library layer would provide most of
Common LISP's functionality. Additional layers could implement
less-standardized functions.

Finally, Richard calls for more openness among developers.
"The business leadership of the AI community seems to have adopted
the worst traits of business practice: secrecy, mistrust, and run-
up-the-score competitiveness." If the language is to survive, its
application developers, expert-systems vendors, and LISP vendors
must work aggressively for a faster, smaller, more deliverable
product.