Newsgroups: comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!newsfeed.pitt.edu!gatech!news.mathworks.com!fu-berlin.de!news.dfn.de!news.dkrz.de!news.rrz.uni-hamburg.de!news.Hanse.DE!wavehh.hanse.de!cracauer
From: cracauer@wavehh.hanse.de (Martin Cracauer)
Subject: Re: ANSI CLISP: strengths vs. weaknesses?
Message-ID: <1996Oct18.115909.28857@wavehh.hanse.de>
Organization: BSD User Group Hamburg
References: <slrn55n3fg.5p.psci@teleport.com> <1996Oct10.100654.824@wavehh.hanse.de> <325E98A0.44CD@franz.com>
Date: Fri, 18 Oct 96 11:59:09 GMT
Lines: 124

Jim Veitch <jim@franz.com> writes:

>Martin Cracauer wrote:
>> 
>> psci@teleport.com (Brett) writes:
>> 
>> >As a programmer in various other languages (procedural), but a recent LISP
>> >onlooker, I am now considering LISP more seriously. And I am curious to
>> >know what other professionals see as the greatest weaknesses of LISP
>> >(various dialects). I see a lot about its advantages, but wish to peer
>> >deeper into this language.
>> 
>> For Common Lisp, I'm unsatisfied mostly with CLOS. It's flexibility
>> greatly damages possible performance improvements and it is not very
>> integrated with the rest of the system. A dylan-like OO system with
>> sealing and standard types being normal classes would be nicer.

>A couple of views from my position as working for a vendor.

>If one writes benchmarks which do nothing but method calls, then
>performance is poorer than C or C++.  But if you write code that does
>other
>things (like an application) then surprising facts emerge:

>1. In an optimized CLOS implementation like Allegro CL, CLOS overhead is
>typically only 10% or so.  So reducing overhead to 0 might speed up your
>application by 10%.  In some cases like very tight graphics loops, the
>overhead becomes significant and sealing would help, but dropping into
>procedural code is very possible to circumvent these cases.  But in
>these
>cases sealing would be great.

The 10% message call overhead number is probably not wrong, but under
certain assumptions.

I thought a bit about what I feel to be "wrong" with CLOS. It is
certainly not that "CLOS is slow", rather, "CLOS's flexibility
requires to use it in the right places".

CLOS is not to Lisp what C++ is to C. In C++, you can (but don't have
to) put almost everything, even basic functionality of your
application in classes, objects and member functions. It will slow
down, but not too much.

This can't be done with CLOS. Would you think it is right to say that
CLOS is exclusively for higher-level objects and that the basic Common
Lisp functionality should be sufficient for the lower levels?

Then, the 10% number is probably right. I happened to had a bad start
with CLOS, using it to model almost everything in CLOS objects, like I
did when I tried to bring my C programs to C++ (I still use C, not C++
for this, for other reasons than performance).

Obviously, my CLOS code was really bloated and slow. Using CLOS for
tiny objects with low-runtime function calls *is* slow.

It's not only message call overhead. When you define a C++ class with
members of simple data types, these are represented unboxed, without
pointers. No CLOS implementation, as far as I know, can represent
slots without at least one pointer redirection. Then, simple C++
classes usually can use static binding, and therefore inlining.

>2. Many C++ applications run slower than CLOS applications which do
>similar things.  Why?  C++ seals everything and makes it hard to
>experiment.  If you didn't do it right the first time then you never
>do it right.  C++ is a "read-only" language.

Once your objects are of sufficient complexity that even the C++
representation uses some kind of type tagging, pointer indirections
and virtual functions, CLOS will probably be usable again.

>What are the limitations to CLOS?  things like not enough experienced
>programmers, not enough mainstream acceptance and perception that Lisp
>is

I am probably an unexperienced CLOS programmer. I had the same
discussion with Ken Anderson of BBN and other people several times. I
heard many things about how to speed up CLOS.

I have to admit that I didn't understand many of these techniques, for
other, I'm unsure whether they are what I want.

All in all, I think CLOS is a high-level modeling system that can't be
treated like other OO extended extensions or simple OO-only languages
like Java.

It is not trivial to learn to use CLOS right. It's not the unusual
generic functions approach, in fact I like it. I felt to write CLOS
programs with acceptable performance I had to know a lot about the
implementation, to use the right constructs in the right place. This
is true for every program in every language. But to estimate the
runtime behavior of CLOS constructs is more difficult than for plain
Lisp objects. Additionally, Common Lisp implementations with CLOS are
very different from each other, at least when you count free
implementations as well (many have weak CLOS support, but perform well
for basic Common Lisp).

I learned programming mostly from reading other people's sources (and
books, of course). I didn't find much free CLOS code and would
appreciate any pointers. The books I own either teach "how-to-use"
CLOS (not "where-to-use"), in situations where I found CLOS to be
inadequate (complex numbers, points etc.) or they don't use much CLOS
(Graham's and Norvigs books).

>unsuitable appear to have far more effect on the use of Lisp than the
>technical disadvantages.  Of course, some of these mean CLOS/Lisp people
>can end up total winners in getting things done since they don't have
>the same competition.

Here you assume I spoke against Common Lisp as a whole. This is not
the case. In fact, I ended up being very efficient for some projects
*because* I used Lisp. However, I didn't use CLOS and so far I don't
seem to be able to catch up with it. 

I case there's someone with some good pointer where I could educate
myself, and who isn't too upset about my postings, please let me
know. 

Martin
-- 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cracauer@wavehh.hanse.de>  http://www.bik-gmbh.de/~cracauer
"As far as I'm concerned,  if something is so complicated that you can't ex-"
"plain it in 10 seconds, then it's probably not worth knowing anyway"- Calvin
