🚀 go-pugleaf

  Errors-To: commonloops-request@cis.ohio-state.edu
  Sender: commonloops-request@cis.ohio-state.edu
  Date: Wed, 22 May 91 21:15:01 BST
  From: Jeff Dalton <jeff@aiai.edinburgh.ac.uk>
  Subject: Re: CLOS' popularity
  To: "Walter E. Gillett" <gillett@ai.mit.edu>,
      tusveld <tusveld@cis.ohio-state.edu>
  Cc: commonloops@cis.ohio-state.edu, gillett@ai.mit.edu,
      gillett <gillett@cis.ohio-state.edu>

  > My impression is that industrial use of LISP/CLOS is largely confined
  > to research labs and that its use is, if anything, declining.

There are certainly older Flavor based systems in industrial use.  For
example, ALCOA has several Flavor based applications in their plants.

  That is my impression too.  However, it seems rather strange that
  when machines are becomming so much faster and memory so much cheaper
  we find people thinking it will be a big win to move from, say, KEE
  to ProKappa.  The advanatges of a C-based system are relatively less
  than they used to be, I would think.

Yes, from what i've read ProKappa sounds like a cleverly disguised LISP in
C clothing.  This certainly may have some marketing advantages these days,
but who knows about technical.  As time goes on, it may be that C looks at
lot more like LISP.  For example, garbage collection is a major issue in
C++ these days.

  > 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.

  I have encountered a number of cases where Lisp code was faster than C
  or just as fast, but perhaps they are too exceptional.

  There are also cases where Lisp is slower for no good reason, so
  far as I could tell.

  So I think there is room for Lisp to do better here, at least for
  some applications, and I'd be interested in knowing what cases Lisp
  handles poorly.  The various Lisp implementors may be interested too.

I'd be interested too.  Certainly vendors have worried a lot about fixnum
arithmetic, etc.  Unfortunately, in certain implementation LISP will loose
over C.  For example, in some implementations of floating point numbers it
is hard not to cons unnecessary floats.  It is also unfortuantely quite
easy to write very slow programs in LISP that you would never think of
writing in C.  One example is (reduce #'+ (mapcar ...)).

  > 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.

But the foreign function interface is a good way to get to this
"mainstream" software.  If you thought about it, you might be able to write
the interface automatically.  You could even think of LISP as the glue that
holds your C together.  This might give you most of the best of both worlds.

I've only read about programming in C using Motif and Open Look, so correct
me if i'm wrong, but it seems like the first thing they do try to get
around some of the things C is missing - namely lists, keyword arguments,
and closures.  This forces one to program in a style that looks akward to
me.

  The interface to such tools is simple in some implementations.
  However, you are right that the implementors have to prepare the
  ground for you and that your code will be at least somewhat
  implementation-dependent.

  An approach that works well for some applications is have the graphics
  code written in C but running in a separate process connected to Lisp
  by a pipe.  Windows, menus, etc are represented on the Lisp side by a
  "handle" such as, perhaps, a string like "window-1".  Although there
  isn't any standard way to make such a pipe connection, it's fairly
  easy to do it in most Lisps.



  > 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.

  This is indeed a major pain.

I think LISP can learn a lot from C, but what is a comparable C program to
Sun Common LISP?  What are we willing to leave out to make it smaller?

k