|Volume 1: No. 14|
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.