
The Long View on Macintosh Common Lisp (2013) - pjmlp
http://basalgangster.macgui.com/RetroMacComputing/The_Long_View/Entries/2013/2/17_Macintosh_Common_Lisp.html
======
aidenn0
There are no class browsers for Lisp because deep class hierarchies are very
rare.

One example: In many OO APIs it is idiomatic (if not mandatory) to subclass a
base-class in the API in order to customize its behavior. This is extremely
rare in lisp. Behavior is more commonly customized by just defining functions
and either assigning them to slots, or defining new methods on generic
functions for classes that are not typically descendants of classes in the
API.

I've been developing in lisp for years, and I can count on one finger the
number of times I've subclassed a class written by someone else, and I've
never said "This would be so much easier to understand if only I had a class
browser"

~~~
lispm
> There are no class browsers for Lisp because deep class hierarchies are very
> rare.

That's actually false. Deep class hierarchies are quite common in object-
oriented Lisp. Also there are class browsers for Lisp.

> ... to subclass a base-class ... This is extremely rare in lisp.

It is isn't. For example, an application's condition classes will always be a
subclass of something. Only relatively primitive applications will not
introduce new condition classes.

> I can count on one finger the number of times I've subclassed

Then you have never used CLOS or any CLOS-based libraries.

~~~
aidenn0
> Then you have never used CLOS or any CLOS-based libraries.

Does using DEFGENERIC/DEFMETHOD make it CLOS based? If so, then I have used
CLOS and CLOS based libraries; they just weren't particularly object-oriented.
I know that there is more strongly object-oriented lisp code out there, but I
personally haven't run into it.

I'll agree that "Deep class hierarchies are quite common in object-oriented
Lisp." since that is very nearly tautological. I'm not certain, however, how
common object-oriented lisp is. Even within common-lisp there really isn't a
single idiomatic style that is used.

Care to share some examples of more heavily object-oriented lisp projects?

~~~
lispm
LispWorks has a class browser. Its class library has several deep hierarchies
with lots of classes. For example the class for a UI button is called
CAPI:BUTTON. It has 11 CAPI superclasses and its depth for CAPI classes is
six. It also has five subclasses adding more depth.

The minute you write a GUI application in LispWorks, you'll use a macro called
DEFINE-INTERFACE. What does it do? It creates a CLOS class for your
application, which inherits from CAPI:INTERFACE.

You want a new window pane type? Define a subclass of CAPI:OUTPUT-PANE.

For another example: check the class hierarchy of stream classes in Clozure
Common Lisp.

------
mark_l_watson
I really liked Coral Common Lisp. After I ported the ISI Grapher package to
Coral, I gave my Xerox 1108 Lisp Machine to a colleague.

Clozure Common Lisp is very nice, but for some reason I usually use SBCL (and
rarely Franz or clisp). I used SBCL (with QuickLisp) for the last edition of
my Common Lisp book, BTW.

If there had been very good free versions of Common Lisp 20+ years ago, then I
think the language would be more popular today. I think the same is true of
Smalltalk. Today Pharo Smalltalk really is a wonderful programming environment
and it is free. In the 1980s and 1990s it was very expensive to get a
Smalltalk programming environment.

~~~
lispm
I tend to use Clozure CL most of the time. Clozure CL's compiler is a bit more
primitive, but the compiled code is smaller, the compiler is faster, the
runtime is much better (better GC) and it has a basic non-GNU-Emacs IDE on the
Mac.

> f there had been very good free versions of Common Lisp 20+ years ago, then
> I think the language would be more popular today.

This fails to understand a few things. Good versions of Common Lisp did exist
20+ years ago, even free ones. But Common Lisp implementations tend to be
complex systems and thus its not easy to to get this financed over a long
time.

Common Lisp was unpopular between 90s and 2000. A new generation of developers
had to rediscover it to revive some of it: SBCL, ECL, ...

> Today Pharo Smalltalk really is a wonderful programming environment and it
> is free. In the 1980s and 1990s it was very expensive to get a Smalltalk
> programming environment.

Common Lisp has many free and good implementations today.

If you look at Pharo Smalltalk, it's nice, but it has the same limitations
like Squeak and other implementations: it looks and feels non-native. That's
because the UI is non-native.

~~~
ruricolist
To be fair, the compiler is more than a _bit_ more primitive. Clozure doesn't
come close to SBCL where numeric code is concerned. But the garbage collector
really is _much_ better, especially under heavy concurrency.

~~~
lispm
> Clozure doesn't come close to SBCL where numeric code is concerned.

Well, you have to declare everything then you get similar performance.

~~~
ruricolist
I haven't found that to be the case. I don't mean that Clozure's performance
is bad, but optimizing numeric code is SBCL's reason for being. When I
switched from SBCL to Clozure, I had to move things like password hashing out
of Lisp, because I couldn't get acceptable performance out of Ironclad.

~~~
lispm
In my experience you can get excellent numeric performance out of CCL (and
earlier MCL). But there are several issues and it may be a lot of work.

But I definitely agree that the SBCL compiler is a lot better doing these
things and it is much easier there.

------
bsder
Is there a reason why a site that looks like it is from 1998 _requires_
Javascript? Sigh.

Nevermind. I'm tilting at windmills.

