The Long View on Macintosh Common Lisp (2013) | Hacker News Reader

The Long View on Macintosh Common Lisp (2013)

basalgangster.macgui.com

54 pointspjmlp20 comments

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"

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

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

There are plenty of objects in CLIM.

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.

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.

> 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 guess it depends on what you mean by "very good" and how big that "+" is, but weren't there at least two? For people with access to a Unix box (usually via universities, companies, or a shell account), CMUCL was available, typically on SPARC/Solaris, since the mid-80s sometime. And for people running home microcomputers, clisp was freeware on the Atari ST from the late '80s, and released as GPL in 1993, with ports to DOS, Amiga, and Linux.

Kyoto Common Lisp was available in the late-80s, CMUCL on x86 in 1996.

I would suspect that most people using SBCL has more to do with momentum than anything. CCL only became available on x86 fairly recently.

Eight years ago a 64bit x86 version of OpenMCL (aka CCL) appeared for Linux.

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.

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

And they miss so much, because they only get part of what a Common Lisp dev env used to be.

Since the good alternatives are the commercial ones, that most nowadays aren't willing to pay for.

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

Yeah, there is this goal of trying to replicate Smalltalk, the OS, experience, instead of just being another programming language.

I think Pharo is moving into the direction of better native integration, though.

> I think Pharo is moving into the direction of better native integration, though.

Currently its IDE is looking completely non-native on my Mac. No application on my Mac uses hierarchical windows. Pharo does. Its sub-windows are looking alien. It does not use the menubar like it is supposed to do as a Mac application... and so on.

It was discussed as planned at FOSDEM. Not sure for when.

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.

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

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

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.

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.

20 years ago, people were still paying for their compilers.

Heck, we still are in some areas nowadays, outside what usually gets HN attention.

In the 90's SmaltalkWorks price wasn't much different from other tooling. Actually the enterprise was already starting to use Smalltalk.

But then Java came out, and everyone jumped ship.

Did you know Eclipse started out as Visual Age for Smalltalk?

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

Nevermind. I'm tilting at windmills.

Reply on news.ycombinator.com