Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!wuarchive!cs.utexas.edu!rutgers!tut.cis.ohio-state.edu!unreplyable!garbage
From: gillett@AI.MIT.EDU (Walter E. Gillett)
Newsgroups: comp.lang.clos
Subject: CLOS' popularity
Message-ID: <9105181833.AA05092@rice-chex>
Date: 18 May 91 18:33:59 GMT
References: <9105131105.AA13630@hcsrnd>
Sender: welch@tut.cis.ohio-state.edu
Distribution: inet
Organization: CommonLoops
Lines: 49

>Does anyone know of applications written in CLOS that have been delivered?

"SitePlanner", a computer-aided engineering (CAE) software package
used in cleaning up hazardous waste sites.  Developed by ConSolve,
Inc., Lexington, MA.

>Another interesting question is : are there signs that CLOS is gaining
>industrial acceptance? Some time ago I heard that an industrial CAD
>package originally written in C was being ported to CLOS.

My impression is that industrial use of LISP/CLOS is largely confined
to research labs and that its use is, if anything, declining.
ConSolve is considering porting SitePlanner to C++ because of problems
with LISP.  Those problems are (in order of importance to us):

1. Performance.  LISP code is always significantly slower than C code,
even if one works hard to optimize it.  The richness of the language
is wonderful for quick development, but makes optimization difficult.
One has to be very disciplined (e.g., using destructive rather than
copying list operations wherever possible) and the language is
sufficiently remote from the machine that it is not always easy to
understand the efficiency tradeoffs of using different constructs.

Another problem is the amount of run-time overhead resulting from
CLOS's flexibility - on-the-fly class and method redefinition, for
example.  This is great for development, but to achieve reasonable
production speed it should be possible to say "OK, I'm finished
developing" and compile a fast, inflexible production image.

2. Isolation from mainstream software tools.  C programmers can use,
for example, the Motif and Open Look GUI toolkits directly.  LISP
programmers either have to build a foreign function call interface to
a C-based application or wait for someone else to provide one.
Foreign function calling is not part of the Common LISP standard
(therefore the resulting interface is not portable across different
LISP implementations), and debugging in a hybrid LISP/C environment is
very difficult.

3. Memory hog.  The base development image for Sun Common LISP takes
14 MB!  While there are tools for reducing delivery image size, the
results are still much larger than a comparable C program.

4. Recruiting.  It's a lot easier to hire C programmers than LISP
programmers.

In short, LISP is a wonderful prototyping tool, but is not viable for
commercial products (with the exception of specialized niches such as
expert systems).  C++ may be less powerful, but it is far more
practical.