Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!decwrl!pa.dec.com!src.dec.com!meehan
From: meehan@src.dec.com (Jim Meehan)
Newsgroups: comp.lang.lisp
Subject: Re: MS Windows 3.0 version of lisp?
Message-ID: <1991May10.110428.28723@src.dec.com>
Date: 10 May 91 18:04:28 GMT
Sender: news@src.dec.com (News)
Organization: DEC Systems Research Center
Lines: 37
Originator: meehan@srcf2b.pa.dec.com

I've seen but haven't used Gold Hill's MS-Windows-compatible version
of Common Lisp, but I alsoused to work for a company that used GC Lisp
from its very earliest days, and indeed, things were rocky back then.
Most of Common Lisp wasn't there.  But over the years, things got much
better, and we actually used GC Lisp in some commercial products.

Gold Hill as a company has had its ups and downs, more severe than
most companies of its ilk, but they're still there, which is no mean
feat.  They got on the Expert System Tool/Shell/Lifestyle bandwagon
a little late, just as lots of other people were starting to get off.
Their home-grown windows effort also seemed to me to be a step in the
wrong direction.  In the newly reincarnated company, they made what
I consider a very smart move: they essentially ditched the expert-system
stuff and piggybacked on MS Windows to provide multitasking and all
the other goodies that come with that package, in addition to windows,
of course.  ("If it's better to buy it, don't build it.")

It's true that GC Lisp running on small-memory machines won't give
you the performance of a full-blooded Lisp on a full-blooded machine,
but there's a 30-zillion-true-blue-PC market-niche out there, so it's
not as if they're selling to an empty house.  Actually, we thought
that GC Lisp made a much better delivery platform than development
platform; our customers didn't want Lisp -- they didn't want to HEAR
about Lisp -- they just wanted their application to run fast.

Steve Mitchell complains about GC Lisp's non-compacting garbage
collector.  Perhaps Gold HIll plans by now to revise it, but not all
programs will fragment unto death.  It's also worth mentioning that
because it didn't compact, it was ridiculously fast.  The little "GC"
message would light up and go off about a second later; for some of
our applications, we stopped worrying entirely about dynamic storage
allocation, either because the program wasn't going to fragment memory
(that is, it allocated and deallocated objects of just a few sizes),
or the program wasn't the sort that would take a long time to run.
Anyway, there IS a tradeoff here; it's not as if a compacting,
ephemeral, dual-carb, tinted-windows garbage collector is the only
reasonable implementation.