Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!tut.cis.ohio-state.edu!unreplyable!garbage
From: jeff@aiai.edinburgh.ac.uk (Jeff Dalton)
Newsgroups: comp.lang.clos
Subject: Re: CLOS' popularity
Message-ID: <16144.9105222015@subnode.aiai.ed.ac.uk>
Date: 22 May 91 20:15:01 GMT
Sender: welch@tut.cis.ohio-state.edu
Distribution: inet
Organization: CommonLoops
Lines: 49

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

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.

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

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

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.

-- jd