Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!ub!uhura.cc.rochester.edu!rochester!pt.cs.cmu.edu!o.gp.cs.cmu.edu!ram
From: ram+@cs.cmu.edu (Rob MacLachlan)
Newsgroups: comp.lang.clos
Subject: Re: CLOS' popularity
Message-ID: <1991May28.033548.26907@cs.cmu.edu>
Date: 28 May 91 03:35:48 GMT
References: <9105131105.AA13630@hcsrnd> <9105181833.AA05092@rice-chex>
Sender: netnews@cs.cmu.edu (USENET News Group Software)
Distribution: inet
Organization: School of Computer Science, Carnegie Mellon
Lines: 72

I'd like to point out that (at least in the original message) there was more
substance to this thread than "C good, Lisp bad".  Pretty much everyone who is
starting a large new Lisp system is using CLOS, so the real question is "when
is programming in Common Lisp appropriate?"

>From: gillett@AI.MIT.EDU (Walter E. Gillett)
>Subject: CLOS' popularity
>Date: 18 May 91 18:33:59 GMT
>
>"SitePlanner", a computer-aided engineering (CAE) software package used in
>cleaning up hazardous waste sites.  My impression is that industrial use of
>LISP/CLOS is largely confined to research labs [...]  ConSolve is considering
>porting SitePlanner to C++ because of problems with LISP.  [The usual Lisp
>problems...]
>
>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).

I am a Lisp implementor, and a Lisp advocate, but I think a lot of damage has
been done by advocating Lisp as being:
    "The same as FORTRAN/C/Ada, only better". 

Many of Lisp's efficiency problems can be (and are being) greatly reduced
through improved compilers, tuning, delivery and foreign interface tools, but
as it stands today, given realistic Lisp and C programs that implement the same
algorithm, the C program is guaranteed to be somewhat faster (1.5x to 3x) and
much smaller (2x to 5x).

C's problems with incremental development, debugging and prototyping can be
(and are being) reduced in sophisticated C programming environments such as
Saber C, but as it stands today, Lisp prototyping environments have more
functionality and are more cost-effective than comparable C prototyping
environments.

In addition to these contemporary (but subject to change) differences between
Lisp and C programming environments, there is also the inherent difference
between high-level and low-level programming.  In high-level programming, you
use (and reuse) powerful operations that are very distant from the hardware
implementation.  In low-level programming, the hardware implementation is
obvious.  You can program at different levels in any language, but Lisp
encourages high-level programming, and C excels at low-level programming.

Many of the advantages (and disadvantages) of Lisp are exactly the advantages
(and disadvantages) of high-level programming.  High-level programming is
easier, but produces a less efficient result.

The place where Lisp delivers its benefits is in the pre-production parts of
research and development.  Lisp is very appropriate in research labs, and is
also generally effective for rapid prototyping.  Programs that are long-lived
(subject to much evolution), but that are sold in small volumes for very high
prices may also gain significant benefits during their long maintenance phase.

The question key is:
  "When can a company get away with releasing a product written in Lisp?"

I think that the answer is basically "when there is no competition."  This is
not as restrictive as it might seem; because Lisp excels at rapid development,
it is easy for a Lisp program to be the first to market.  But in order to hold
onto market share after the first couple of years, the company must either:
 -- Continue to add useful functionality to the Lisp program, maintaining a
    powerful technological advantage, or
 -- Reimplement a production version, probably in a lower-level language.

The other way in which there may be no competition is under contract.  If
someone needs a very specialized program, they won't be able to buy it in a
competitive market.  Instead, they will have to take bids to develop the
program.  In this situation, the customer is forced to directly pay development
costs; if you program using an environment that reduces development costs, you
can come in with a lower bid.

  Robert A. MacLachlan