I have been working with Lisp for something less than a year now, but I
have grown to really enjoy the language. Unfortunately, it seems that
the language may not remain usable for many applications for much
longer. There are several problems with using the language that I would
like to bring up. If these problems are really non-issues please let
me know. If the solutions to any of these problems is readily apparent
please point me in the correct direction.
In this article I am referring strictly to freeware Lisp implementations
and tools. Although comments about commercial tools and implementations
are welcome (even requested), I don't think that Lisp's fate will change
if only commercial tools are available. Unless younger people become
interested in using the language it will not be in use for most
applications in just a few years. Most of this market has limited
funding and will be spending it on tools for C, C++, and Java not Lisp.
I have tried to order these from most to least important, but you may
have other needs.
1) There isn't an obvious way to distribute my work in a reasonable
form. On my Linux box The Free Software Foundation's color ls program
takes up 37,980 bytes on my disk. In Lisp I can't write and distribute
a "Hello World" program this small. Is there a way to distribute Lisp
programs that don't require 10 Meg of disk or more? Would it be
possible to write an ls program for Linux that required less than 100
kilobytes and could be distributed as an executable?
2) There are very few freeware tools available to the lisp programmer
outside of those that are standard in a lisp system. In C I use DDD to
debug my code. It is a motif based application that interacts with gdb
to ease my debugging time. Are tools like this available for Lisp? Are
there any projects that are currently working on one?
3) The seeming inactivity of the freeware community in the Lisp language
indicates that many of these problems will persist. It also means that
the projects that I work on are very unlikely to be written in Lisp.
There just don't seem to be many freeware projects using lisp.
Am I wrong here?
4) Speed. Lisp is slower than C. I think it is worth it. Perl is also
slower. So is Java. Unfortunately Lisp is the only language I know of
that has been saddled with such a reputation of lethargy. The only thing
I knew about lisp before I learned it was that it was slow.
As computers get faster, and compilers improve, this is becoming less
and less important, but the reputation Lisp has gained remains very
important. The only solution I see to this problem is the free
distribution of speedy Lisp applications (which many of us would love to
write anyway). See (1) above.
5) Standardization - The tools available for Lisp don't seem to be
conforming. I am compiling garnet in the background now. It uses it's
own version of an object system because CLOS is too slow. I don't mind
this all that much, but it is a bit annoying. Is CLOS really that slow?
If so, why? Often I see applications that use special features of the
Lisp in which they were written. This seems to be much more prevalent
in the Lisp community than it is in the C/Unix community. Portable code
seems to be of very limited importance.
6) Because of the limited number of applications available for lisp
there seems to be a shortage of sample code. I have seen the Lisp
repositories and I know about www.cons.org. In comparison to C there
just don't seem to be that may open source applications for review.
7) It is more difficult to learn the complexities of the language. It
is easy to get started, but the learning curve lasts quite some time. I
guess this is just because it is a big language, but there don't seem to
be that many places on the web to find assistance... there isn't much out
there for the intermediate level programmer. There are several fine
books available, but even these gloss over topics like optimization,
delivery ( see (1) ), using lisp with other languages, using lisp with
sockets, using lisp with X, and so on..... Documentation about all of
these things is available for almost any platform you want to run C on.
Understand that I do like Lisp... this article is just an expression of
my frustration.. I would like to see the language survive. I am
willing to work help make sure that happens, and make it more useful
for my own needs.
Putting on my asbestos underwear..
--
Kenneth P. Turvey <·······@pug1.SprocketShop.com>
When you choose the lesser of two evils, always remember that it is
still an evil.
-- Max Lerner
In article <······················@www.sprocketshop.com>,
·······@pug1.sprocketshop.com (Kenneth P. Turvey) wrote:
>I have been working with Lisp for something less than a year now, but I
>have grown to really enjoy the language. Unfortunately, it seems that
>the language may not remain usable for many applications for much
>longer. There are several problems with using the language that I would
>like to bring up. If these problems are really non-issues please let
>me know. If the solutions to any of these problems is readily apparent
>please point me in the correct direction.
>
Sigh, here we go again... Maybe we should turn this thread into an FAQ:
"Why isn't Lisp more like my favorite programming language/environment?"
>In this article I am referring strictly to freeware Lisp implementations
>and tools. Although comments about commercial tools and implementations
>are welcome (even requested), I don't think that Lisp's fate will change
>if only commercial tools are available. Unless younger people become
>interested in using the language it will not be in use for most
>applications in just a few years. Most of this market has limited
>funding and will be spending it on tools for C, C++, and Java not Lisp.
>
Frankly, I'm not sure whether you're trolling or genuinely concerned. I'm
going to assume the latter.
First off, Lisp implementations are _big_. Although the syntax (and
therefore parsing) is trivial, writing a decent compiler is not. And the
"runtime library" that composes the bulk of Lisp is a pretty big deal --
just the ANSI standard CL definition has (I think) well over a thousand
built in functions. Keyword and optional arguments on these let many of
these functions perform the equivalent of several functions, compared to a
language with more restrictive ways of defining functions. And the built
in functions are not trivial -- you'd pay hundreds, maybe thousands, of
dollars to purchase these as add-ins to a traditional language or (if you
were a commercial developer) to reinvent them yourself.
I know of several freeware implementations built by a single developer.
Bruno Habile wrote CLISP to run on Wintel, and Roger Corman wrote
PowerLisp to run on Macintosh. Both are heroic efforts. Nevertheless, I
find it preferrable to invest $120 for each upgrade to MCL. CLISP, when I
tried it, was still lagging the standard definition of Common Lisp. It
also benchmarked about five times slower than a compiled implementation,
since it compiles to byte code rather than machine language. PowerLisp
has never -- at least in my experience with it -- been robust enough to
use for serious work. And both are essentially text-based environments;
neither offers the comforting amenities of the Allegro Common Lisp/Windows
or Macintosh Common Lisp environments.
I know that I'm basically echoing your observations of the freeware
environments. My point is that it takes _many_ person-years of effort to
develop a really good Lisp developement environment -- MCL has, for
example, been under development since the mid-80s with an average team
size of maybe three or four people (and lots of contributions from their
user community.)
>I have tried to order these from most to least important, but you may
>have other needs.
>
>1) There isn't an obvious way to distribute my work in a reasonable
>form. On my Linux box The Free Software Foundation's color ls program
>takes up 37,980 bytes on my disk. In Lisp I can't write and distribute
>a "Hello World" program this small. Is there a way to distribute Lisp
>programs that don't require 10 Meg of disk or more? Would it be
>possible to write an ls program for Linux that required less than 100
>kilobytes and could be distributed as an executable?
>
If you want to ship yet another ls, by all means do it in C or C++. Use
the right tool for the job. Lisp is typically used for large, complex,
knowledge-based systems. Its differentiator is that it provides better
facilities for manipulating complex data structures. (Yes, you can
_eventually_ do the same things in C or C++, but you'll find that you
spend more time writing infrastructure code than you do solving the given
problem.)
>2) There are very few freeware tools available to the lisp programmer
>outside of those that are standard in a lisp system. In C I use DDD to
>debug my code. It is a motif based application that interacts with gdb
>to ease my debugging time. Are tools like this available for Lisp? Are
>there any projects that are currently working on one?
>
One more time: Lisp is not Unix. Lisp is not C/C++. Lisp environments
tend to be self-contained. The environments which are actively developed,
supported, and used (e.g. MCL) tend to foster the development of a
plethora of relevant tools and utilities which work _within the Lisp
environment._
>3) The seeming inactivity of the freeware community in the Lisp language
>indicates that many of these problems will persist. It also means that
>the projects that I work on are very unlikely to be written in Lisp.
>There just don't seem to be many freeware projects using lisp.
>Am I wrong here?
>
I'd like to find a way for you to be right about this...
If you mean that there is no freeware effort to develop Lisp
compilers/environments, I'd point to the CMUCL and LispOS/LispVM
initiatives. There are also the previously mentioned single-author
projects. Finally, the major vendors -- Digitool, Franz, and Harlequin --
all offer demonstration versions of their commercial products.
If you mean that there's no freely available code written in Lisp, you
have only to look at the CMU AI Repository or Digitool's FTP site for
gigabytes of counterexamples.
If you mean that no one is publishing interesting new freely distributable
applications using Lisp, then you haven't yet heard about the CL-HTTP web
server.
Hmm, I guess you're wrong, after all. Unless you mean that no one writes
Unix shell commands in Lisp. Oops, sorry, I forgot about scsh...
>4) Speed. Lisp is slower than C. I think it is worth it. Perl is also
>slower. So is Java. Unfortunately Lisp is the only language I know of
>that has been saddled with such a reputation of lethargy. The only thing
>I knew about lisp before I learned it was that it was slow.
>As computers get faster, and compilers improve, this is becoming less
>and less important, but the reputation Lisp has gained remains very
>important. The only solution I see to this problem is the free
>distribution of speedy Lisp applications (which many of us would love to
>write anyway). See (1) above.
>
Reputation hurts only to the extent that incorrect information continues
to be repeated long after it ceases to be valid. A good Lisp compiler can
go head to head with a good C or C++ compiler. And when you level the
playing field by requiring the C/C++ program to offer comparable
functionality and safety/robustness the balance will tip in favor of Lisp,
which offers predictable, defined behavior in the areas of arithmetic,
storage management, and condition handling.
There will always be a place for Lisp and for C/C++. They do different
things well. It does no good to whine about a percieved lack of free,
speedy Lisp applications when you can't articulate what it is that you'd
like to do. There are plenty of people using Lisp for serious commercial
product development, and lots of free add-ins for the use of developers
who own commercial Lisp products.
I've pointed out some substantial freeware that is written in Lisp. Is it
a problem that the Lisp community has produce a small number of
significant applications, rather than a large number of trivial
applications?
>5) Standardization - The tools available for Lisp don't seem to be
>conforming. I am compiling garnet in the background now. It uses it's
>own version of an object system because CLOS is too slow. I don't mind
>this all that much, but it is a bit annoying. Is CLOS really that slow?
>If so, why? Often I see applications that use special features of the
>Lisp in which they were written. This seems to be much more prevalent
>in the Lisp community than it is in the C/Unix community. Portable code
>seems to be of very limited importance.
>
Garnet has been discussed before on this list as an example of a Lisp
program that is not properly written w.r.t. performance concerns. The
Garnet developers switched to C++ rather than attempt to optimize their
Lisp code base, citing lack of funding to continue the Lisp work.
CLOS is part of the standard Common Lisp language. Implementations vary
in their performance. CLOS offers tremendous expressive power and
generality. If your application requires what CLOS offers, you'll be hard
pressed to find a better replacement. If the expressiveness and
generality gets in the way of performance, there are plenty of other data
types built in to Lisp -- you have to make the proper engineering
tradeoffs in your design. There is no such thing as a "sufficiently smart
compiler" -- not in Lisp, nor in any other language.
My experience has been that Common Lisp code ports quite nicely across
platforms. The few incompatible changes made along the way from the first
Common Lisp definition to the ANSI standard are easy to identify and
change. Compared to C++, the Common Lisp specification was remarkably
stable over its six years of development; the Common Lisp committee
codified existing practice.
The biggest single headache in porting Common Lisp code -- in my
experience -- has been the differing pathname syntax for files referenced
from Lisp code. Note that this problem is easily avoided by using a built
in _portable_ pathname representation; most programmers find it easier to
rely upon the native pathname strings offered as a language extension by
virtually all environments.
Once past these purely mechanical aspects of portation, Lisp code just
works. Unlike C/C++ you don't have to worry about limited numeric
precision or indeterminate behavior of signedness or overflow. Just going
from one version of a single vendor's C++ compiler to the next caused more
portation problems than all the Lisp code I've ever worked with. God help
you if you think you can write substantial C++ code that ports cleanly
from one platform to the next, and won't require revision as vendors catch
up with the language spec.
>6) Because of the limited number of applications available for lisp
>there seems to be a shortage of sample code. I have seen the Lisp
>repositories and I know about www.cons.org. In comparison to C there
>just don't seem to be that may open source applications for review.
>
This is a matter of opinion, I guess. The CMU AI repository is available
on CD-ROM; there's about 5GB -- much of it Lisp source code -- in that
collection. The MCL CD-ROM (and the Digitool FTP site) contains well over
100MB of user-contributed code.
Consider also that Lisp source code is denser than C++ source. Source
code is available for the book "Artificial Intelligence" by Dean, Allen,
and Aloimonos. The code was first written in Lisp, then ported to C++.
The C++ source, despite having reduced functionality, was about six times
larger than the Lisp source.
>7) It is more difficult to learn the complexities of the language. It
>is easy to get started, but the learning curve lasts quite some time. I
>guess this is just because it is a big language, but there don't seem to
>be that many places on the web to find assistance... there isn't much out
>there for the intermediate level programmer. There are several fine
>books available, but even these gloss over topics like optimization,
>delivery ( see (1) ), using lisp with other languages, using lisp with
>sockets, using lisp with X, and so on..... Documentation about all of
>these things is available for almost any platform you want to run C on.
>
There are fewer grey areas in the definition of Common Lisp, therefore
less need of books that offer advice on how to work around a poor language
definition. There are a small number of _excellent_ texts on developing
Lisp programs. The one that most directly addresses your concerns is
"Paradigms of Artificial Intelligence Programming" by Norvig. (See my web
site for capsule descriptions of quite a few other Lisp books.)
Optimization details tend to be vendor specific, and the commercial
vendors publish the necessary information in their products'
documentation.
Vendors that provide Lisp environments for Unix/X platforms provide
appropriate documentation. It doesn't do much good to ask for X on
Windows or Macintosh.
Network communication, lightweight processes (a.k.a. threads), and
interaction with other languages (FFI, in Lisp terminology) are not
standardized. All of the commercial vendors offer these functions and
document their own implementation. For now, you have to write wrappers if
you want a portable implementation of any of these (or look on the net to
find where people have alredy done so.) When the Common Lisp committee
reconvenes, maybe they'll do something about this (assuming that existing
practice is sufficiently mature to warrant standarization.)
>
>
>
>Understand that I do like Lisp... this article is just an expression of
>my frustration.. I would like to see the language survive. I am
>willing to work help make sure that happens, and make it more useful
>for my own needs.
>
What are your needs? What kinds of programs do you want to write in
Lisp? Is Lisp well suited for your needs, or are you just looking for an
excuse to use the language?
>
>
>Putting on my asbestos underwear..
--
David B. Lamkins <http://www.teleport.com/~dlamkins/>
········@teleport.com (David B. Lamkins) writes:
> In article <······················@www.sprocketshop.com>,
> ·······@pug1.sprocketshop.com (Kenneth P. Turvey) wrote:
> >5) Standardization - The tools available for Lisp don't seem to be
> >conforming. I am compiling garnet in the background now. It uses it's
> >own version of an object system because CLOS is too slow. I don't mind
> >this all that much, but it is a bit annoying. Is CLOS really that slow?
Actually from the garnet FAQ:
-----------------------------------------------------------------------
[9] Why doesn't Garnet use CLOS?
CLOS is the standard Common Lisp Object System, and Garnet uses a
custom object system (called KR) instead. There are a number of
reasons for this.
The main reason is that Garnet uses a prototype-instance model, rather
than the conventional class-instance model supported by CLOS. We have
found the prototype model to be more effective for user interface
prototyping and construction. A second reason is performance: it
appears that KR is more efficient than CLOS for most standard
operations. Since we have control of KR, we can also optimize the
performance of constraint satisfaction, which would require extra
overhead in CLOS.
-----------------------------------------------------------------------
I would rather read this as: we do not need the generality that CLOS
offers and for our application another model is better so we use a
different architecture. That this is possible at all with relatively
little effort (KR isn't that big) shows the versatility and power of
Lisp. I'd like to see somebody write a Self like object system for
C++.
> >If so, why? Often I see applications that use special features of the
> >Lisp in which they were written. This seems to be much more prevalent
> >in the Lisp community than it is in the C/Unix community. Portable code
> >seems to be of very limited importance.
> >
In my experience Lisp is orders of magnitude more portable than most
C++ I had the displeasure to port. Most C++ programmers seem to think
MFC exists on every machine in the universe. Even pre ANSI CL code
rarely needs more than a few cosmetic changes and most CL
implementations have backward compatibility modes if you don't want to
take the time.
>
> Garnet has been discussed before on this list as an example of a Lisp
> program that is not properly written w.r.t. performance concerns. The
> Garnet developers switched to C++ rather than attempt to optimize their
> Lisp code base, citing lack of funding to continue the Lisp work.
What's specifically wrong with it? It seems fast enough on my Linux
486 DX2/66 with 16MB RAM.
> This is a matter of opinion, I guess. The CMU AI repository is available
> on CD-ROM; there's about 5GB -- much of it Lisp source code -- in that
> collection. The MCL CD-ROM (and the Digitool FTP site) contains well over
> 100MB of user-contributed code.
Where can you get that CMU AI cd?
> There are fewer grey areas in the definition of Common Lisp, therefore
> less need of books that offer advice on how to work around a poor language
> definition. There are a small number of _excellent_ texts on developing
> Lisp programs. The one that most directly addresses your concerns is
> "Paradigms of Artificial Intelligence Programming" by Norvig. (See my web
> site for capsule descriptions of quite a few other Lisp books.)
Agreed. I don't think anybody here is holding his/her breath for
"Common Lisp for Dummies" or "Learn CL in 24 hours". Another book from
Paul Graham on the other hand...
--
Lieven Marchand <···@bewoner.dma.be>
------------------------------------------------------------------------------
Few people have a talent for constructive laziness. -- Lazarus Long
In article <············@xenon.inbe.net>, Lieven Marchand
<···@bewoner.dma.be> wrote:
>········@teleport.com (David B. Lamkins) writes:
>
>> In article <······················@www.sprocketshop.com>,
>> ·······@pug1.sprocketshop.com (Kenneth P. Turvey) wrote:
[snip]
>> Garnet has been discussed before on this list as an example of a Lisp
>> program that is not properly written w.r.t. performance concerns. The
>> Garnet developers switched to C++ rather than attempt to optimize their
>> Lisp code base, citing lack of funding to continue the Lisp work.
>
>What's specifically wrong with it? It seems fast enough on my Linux
>486 DX2/66 with 16MB RAM.
>
That was from memory, perhaps based upon discussions seen in this newsgroup.
The official explanation found at
<http://www.cs.cmu.edu/afs/cs/project/garnet/www/letter-no-support.html>
does not mention performance issues, but rather the loss of the key
programmer on the project.
If you do a DejaNews search on Garnet in comp.lang.lisp, you'll find the
Garnet FAQ, which contains this in response the the question about why
they switched to C++:
"* Speed: We spend 5 years and lots of effort optimizing our Lisp code,
but it was still pretty slow on "conventional" machines. The initial
version of the C++ version, with similar functionality, appears to be
about THREE TIMES FASTER than the current Lisp version without any
tuning at all."
I didn't dig further, but I do recall seeing examples of sub-optimal
(maximally pessimal?) Lisp source code from Garnet.
>> This is a matter of opinion, I guess. The CMU AI repository is available
>> on CD-ROM; there's about 5GB -- much of it Lisp source code -- in that
>> collection. The MCL CD-ROM (and the Digitool FTP site) contains well over
>> 100MB of user-contributed code.
>
>Where can you get that CMU AI cd?
>
It's published by Prime Time Freeware, ISBN 1-881957-11-X. Check with
your bookstore or <http://www.ptf.com/ptf/products/AI/>.
>> There are fewer grey areas in the definition of Common Lisp, therefore
>> less need of books that offer advice on how to work around a poor language
>> definition. There are a small number of _excellent_ texts on developing
>> Lisp programs. The one that most directly addresses your concerns is
>> "Paradigms of Artificial Intelligence Programming" by Norvig. (See my web
>> site for capsule descriptions of quite a few other Lisp books.)
>
>Agreed. I don't think anybody here is holding his/her breath for
>"Common Lisp for Dummies" or "Learn CL in 24 hours". Another book from
>Paul Graham on the other hand...
Amen.
--
David B. Lamkins <http://www.teleport.com/~dlamkins/>
>>>>> "DBL" == David B Lamkins <········@teleport.com> writes:
[... from garnet docs.:]
DBL> "* Speed: We spend 5 years and lots of effort optimizing our
DBL> Lisp code, but it was still pretty slow on "conventional"
DBL> machines. The initial version of the C++ version, with
DBL> similar functionality, appears to be about THREE TIMES FASTER
DBL> than the current Lisp version without any tuning at all."
DBL> I didn't dig further, but I do recall seeing examples of
DBL> sub-optimal (maximally pessimal?) Lisp source code from
DBL> Garnet.
Usually Rainer Joswig makes this argument but this time I will...
Assuming that Garnet is indeed slow and inefficient, at this point
it doesn't really matter for most tasks. Window creation menus etc.
are not things you need to do millions of times per second.
Besides both memory and CPU power is plentiful now, and I suspect what
they called "conventional" back then is more than three times slower
than what's "conventional" now. It might indeed be true that there is
some sub-optimal code in Garnet, and I do remember people calling KR (the
underlying object system) intrinsically slow but I doubt very much
it matters on today's hardware. I remember it being very convenient to
use with excellent documentation. As an anectodal data point: it took me
half a day to write something reasonably useful with Garnet as opposed
to three-four days of part time agony with CLIM (and I also had the benefit
of old Symbolics CLIM manuals).
Garnet does look ugly IMHO...
cheers,
BM
Bulent Murtezaoglu <··@acm.org> writes:
> DBL> I didn't dig further, but I do recall seeing examples of
> DBL> sub-optimal (maximally pessimal?) Lisp source code from
> DBL> Garnet.
>
> Usually Rainer Joswig makes this argument but this time I will...
Ken Anderson looked at the code (if I remember his Usenet postings right)
and found that they were not writing very efficient code.
> Assuming that Garnet is indeed slow and inefficient, at this point
> it doesn't really matter for most tasks.
That's right. I've tried Garnet with CMUCL years ago and it
was not very fast. Especially the GC was ***really*** painful.
On a decent system this should be different nowadays.
Actually I think it was a fault not use CLOS. They could have get
rid of their prototype approach or they could have implemented
it on top of CLOS. It's like building a car and wanting to
build new roads, too. The prototype approach may be more
flexible. MCL's former versions used "Object Lisp". Later
after CLOS became popular the old GUI code became
obsolete. I can't remember that many people complained
or that writing UI code now is significantly more difficult.
> Garnet does look ugly IMHO...
True.
I guess it is time to switch the language again. To Java.
On 25 Jun 1998 09:11:09 +0200, Rainer Joswig <······@lavielle.com> wrote:
>
>Actually I think it was a fault not use CLOS. They could have get
>rid of their prototype approach or they could have implemented
>it on top of CLOS. It's like building a car and wanting to
>build new roads, too. The prototype approach may be more
>flexible. MCL's former versions used "Object Lisp". Later
>after CLOS became popular the old GUI code became
>obsolete. I can't remember that many people complained
>or that writing UI code now is significantly more difficult.
>
>Bulent Murtezaoglu <··@acm.org> writes:
>> Garnet does look ugly IMHO...
>
>True.
>
>I guess it is time to switch the language again. To Java.
I hope that isn't necessary..
What are people's opinions about windowing systems for Common Lisp. I
have never used any of them and I am trying to find one to familiarize
myself with.
I have looked at the free CLIM source, but unfortunately I can't get it
to build under CMUCL. It is looking for a package called MK (any help
would be appreciated). Garnet won't build either.. It take hours to
find this out unfortunately.
Is there a good, freely available windowing system for CMUCL under
Linux?
--
Kenneth P. Turvey <·······@pug1.SprocketShop.com>
Reasonable people adapt themselves to the world. Unreasonable people
attempt to adapt the world to themselves. All progress, therefore,
depends on unreasonable people.
-- George Bernard Shaw
[...]
KPT> Is there a good, freely available windowing system for CMUCL
KPT> under Linux?
I haven't tried it under CMUCL, but Garnet can be built with minimal
hassle under Allegro for Linux (4.3). I was able to bring it up
and run the demos by only changing a few #+'s that had to do with allegro
version. Didn't try to do any real work with it though, YMMV.
If I have time I'll go back and document (and possibly patch) how it
can be done at some point, but don't hold your breath.
BM
·······@pug1.sprocketshop.com (Kenneth P. Turvey) writes:
> >I guess it is time to switch the language again. To Java.
>
> I hope that isn't necessary..
Not for me, but maybe for the Garnet/Amulet developers. ;-)
> I have looked at the free CLIM source, but unfortunately I can't get it
> to build under CMUCL. It is looking for a package called MK (any help
> would be appreciated). Garnet won't build either.. It take hours to
> find this out unfortunately.
>
> Is there a good, freely available windowing system for CMUCL under
> Linux?
A good question.
Looking from the Lisps under Unix:
LispWorks: CLX, CLUE, CAPI, LispWorks Toolkit, CLIM as an add on.
ACL: CLX, Common Windows, CLM, CLIM as an add on. Maybe something else in the future (Win32-based).
CLisp: ???
CMU CL: CLX and ???
GCL: CLX
ECL: ?
Liquid CL: ?
Open Genera: CLX, Dynamic Windows, CLIM, TV, ...
... ?
Looking from the libraries:
CLX: Basic X support. Widely used. Low-level.
CLUE: on top of CLX, from TI, mostly dead.
CLIO: on top of CLUE, from TI, dead
CLINC: on top of CLX, not usable
CAPI: single Vendor
Common Windows: single Vendor
CLM: for Motif, mostly dead?, with interface builder
Garnet: on top of CLX, mostly dead
XIT: on top of CLX, dead?
CLIM: portable, no free version
CL-HTTP: portable, free version, "limited" UI capabilities
Dynamic Windows: single vendor
...
So, the simple answer is that there is no standard UI toolkit.
Most free versions are not under active development.
The only cross platform (X, Genera, Windows, MCL) UIMS (e.g. CLIM)
is not freely available. Vendors have their own ideas when
it comes to UIs. I guess some software companies have their
own UI code, too (Chalkbox from BBtech, http://www.bbtech.com/ChalkBox.html, etc.).
See also: http://www.elwoodcorp.com/alu/table/tools.htm#guitool
I know, this is puzzling. Has anybody a better answer? More to add?
In article <············@lise.lavielle.com>,
Rainer Joswig <······@lavielle.com> writes:
> I know, this is puzzling. Has anybody a better answer? More to add?
Unforunately, no. I've considered this one of the major shortcomings of CL
for quite some time.
Mike McDonald
·······@mikemac.com
Rainer Joswig <······@lavielle.com> wrote:
> ...
>Looking from the Lisps under Unix:
>
>LispWorks: CLX, CLUE, CAPI, LispWorks Toolkit, CLIM as an add on.
>ACL: CLX, Common Windows, CLM, CLIM as an add on. Maybe something else in the future (Win32-based).
Common Graphics with ACL5 (needs Mainsoft - as far as I know)
>CLisp: ???
>CMU CL: CLX and ???
>GCL: CLX
>ECL: ?
>Liquid CL: ?
>Open Genera: CLX, Dynamic Windows, CLIM, TV, ...
>... ?
>
>Looking from the libraries:
>
>CLX: Basic X support. Widely used. Low-level.
>CLUE: on top of CLX, from TI, mostly dead.
>CLIO: on top of CLUE, from TI, dead
>CLINC: on top of CLX, not usable
>CAPI: single Vendor
>Common Windows: single Vendor
>CLM: for Motif, mostly dead?, with interface builder
>Garnet: on top of CLX, mostly dead
>XIT: on top of CLX, dead?
>CLIM: portable, no free version
>CL-HTTP: portable, free version, "limited" UI capabilities
>Dynamic Windows: single vendor
Common Graphics with ACL5 on some platforms (PC/Windows and some UNIX)
--
Francis Leboutte
··········@skynet.be ········@acm.org http://users.skynet.be/algo
Marre du courrier non sollicit� (spam)? Visitez http://www.cauce.org
Rainer Joswig <······@lavielle.com> writes:
> CMU CL: CLX and ???
I have built and run CLUE, CLIO, CLM, Garnet, and XIT under CMUCL.
You may need to get the versions on www.cons.org, however, to get them
to compile and run. (There's no XIT on www.cons.org, but after a few
minutes of hacking I was able to get it to work.)
However, the only one that I found easily usable was Garnet because it
had enough widgets and documentation for me to figure out how to do
simple things relatively easily. XIT was a close second, but it
seemed to want to create all windows inside it's own top-level window,
so it didn't really work like all other X windows apps.
Ray
·······@pug1.sprocketshop.com (Kenneth P. Turvey) writes:
> I have looked at the free CLIM source, but unfortunately I can't get it
> to build under CMUCL. It is looking for a package called MK (any help
> would be appreciated). Garnet won't build either.. It take hours to
> find this out unfortunately.
What versions are you using, exactly? There is no such thing as a free
CLIM source, but if you mean CLINC, then please have a look
www.cons.org/free-clim/, a user contributed a version that he sais
runs on CMUCL.
As for garnet on CMUCL, the CMUCL distribution area has a ports/
subdirectory with some garnet patches. They patches are trivial
environment adjustments for x86, I never failed building Garnet on
CMUCL in the past, with or with patches.
> Is there a good, freely available windowing system for CMUCL under
> Linux?
Garnet should work. If not, please POST THE ERROR MESSAGES!
Martin
I have a short article about the "Learn X in 24 Hours" craze at
http://www.norvig.com/21-days.html
Paul Graham just sold a Lisp program (and the company built on it) to
Yahoo for $49 million, so after he completes the transition of the
company (in about 2 years), he should have some leisure time to write
some more.
-Peter Norvig
http://www.norvig.com
>>········@teleport.com (David B. Lamkins) writes:
>>
>>Agreed. I don't think anybody here is holding his/her breath for
>>"Common Lisp for Dummies" or "Learn CL in 24 hours". Another book from
>>Paul Graham on the other hand...
>
·····@norvig.com (Peter norvig) writes:
> I have a short article about the "Learn X in 24 Hours" craze at
> http://www.norvig.com/21-days.html
>
> Paul Graham just sold a Lisp program (and the company built on it) to
> Yahoo for $49 million, so after he completes the transition of the
> company (in about 2 years), he should have some leisure time to write
> some more.
Yahoo Store.
http://www.viaweb.com/
Is it really the case that the Yahoo Store product is a lisp based server
solution? I'm trying to sell a prototype network appliance product (internally
to my company) based on lisp, and I like to have these sorts of lisp success
stories handy when I battle anti-lisp bias.
Anybody know which parts of the product are lisp based and which are
"conventional". For instance, the on-line literature says they generate
static pages. Does the lisp help with the page generation, while the pages
are served up by conventional http servers such as Apache? Or is CL-HTTP
used to deliver content?
====
Rainer Joswig <······@lavielle.com> wrote:
>·····@norvig.com (Peter norvig) writes:
>
>> I have a short article about the "Learn X in 24 Hours" craze at
>> http://www.norvig.com/21-days.html
>>
>> Paul Graham just sold a Lisp program (and the company built on it) to
>> Yahoo for $49 million, so after he completes the transition of the
>> company (in about 2 years), he should have some leisure time to write
>> some more.
>
>Yahoo Store.
>
>http://www.viaweb.com/
>
Dave Tenny
············@games.ultranet.com - no spam please
············@ma.ultranet.com writes:
> Is it really the case that the Yahoo Store product is a lisp based server
> solution? I'm trying to sell a prototype network appliance product (internally
> to my company) based on lisp, and I like to have these sorts of lisp success
> stories handy when I battle anti-lisp bias.
The canonical success story should be the publications server
of the President of the United States. It is running
on CL-HTTP on two Symbolics Open Genera systems. You can
see it yourself when you ask the web server via some
client:
CL-USER 2 > (http:show-url-headers "http://www.pub.whitehouse.gov/")
Date: Tue, 23 Jun 1998 21:26:36 GMT
Server: CL-HTTP/67.47 (Symbolics Common Lisp)
Cache-Control: no-cache
Content-type: text/html; charset=ISO-8859-1
Content-Location: http://www.pub.whitehouse.gov/
JCMA says: "what is good enough for the president should be
good enough for you." ;-)
In article <············@lise.lavielle.com>,
Rainer Joswig <······@lavielle.com> writes:
> ············@ma.ultranet.com writes:
>
>> Is it really the case that the Yahoo Store product is a lisp based server
>> solution? I'm trying to sell a prototype network appliance product (internally
>> to my company) based on lisp, and I like to have these sorts of lisp success
>> stories handy when I battle anti-lisp bias.
>
> The canonical success story should be the publications server
> of the President of the United States. It is running
> on CL-HTTP on two Symbolics Open Genera systems. You can
> see it yourself when you ask the web server via some
> client:
>
> CL-USER 2 > (http:show-url-headers "http://www.pub.whitehouse.gov/")
>
> Date: Tue, 23 Jun 1998 21:26:36 GMT
> Server: CL-HTTP/67.47 (Symbolics Common Lisp)
> Cache-Control: no-cache
> Content-type: text/html; charset=ISO-8859-1
> Content-Location: http://www.pub.whitehouse.gov/
>
> JCMA says: "what is good enough for the president should be
> good enough for you." ;-)
Man, what's the world coming to? That's twice in the last two
administrations that I've had to whole heartedly support the President. The
other was "Just say no to brocoli."
Mike McDonald
·······@mikemac.com
The particular example you mention won't generate the impact I want. I want to
show solutions which generate money, and government publication servers just
don't send that message, at least not for the folks I work with. But the Yahoo
Store technology and sale to Yahoo would be of interest.
The preceding paragraph probably shows my own ignorance of the publications
server. Is there a revenue success story associated with it that is worth
relaying?
Thanks (and R. Matthew Emerson for the ACM quote as well).
Rainer Joswig <······@lavielle.com> wrote:
>············@ma.ultranet.com writes:
>
>> Is it really the case that the Yahoo Store product is a lisp based server
>> solution? I'm trying to sell a prototype network appliance product (internally
>> to my company) based on lisp, and I like to have these sorts of lisp success
>> stories handy when I battle anti-lisp bias.
>
>The canonical success story should be the publications server
>of the President of the United States. It is running
>on CL-HTTP on two Symbolics Open Genera systems. You can
>see it yourself when you ask the web server via some
>client:
>
>CL-USER 2 > (http:show-url-headers "http://www.pub.whitehouse.gov/")
>
>Date: Tue, 23 Jun 1998 21:26:36 GMT
>Server: CL-HTTP/67.47 (Symbolics Common Lisp)
>Cache-Control: no-cache
>Content-type: text/html; charset=ISO-8859-1
>Content-Location: http://www.pub.whitehouse.gov/
>
>JCMA says: "what is good enough for the president should be
>good enough for you." ;-)
Dave Tenny
············@games.ultranet.com - no spam please
············@ma.ultranet.com writes:
> The particular example you mention won't generate the impact I want. I want to
> show solutions which generate money, and government publication servers just
> don't send that message, at least not for the folks I work with. But the Yahoo
> Store technology and sale to Yahoo would be of interest.
It is an application, right? I mean, is it interesting whether the application
is written in PERL or CL? Does it matter whether a PERL or a CL application
makes the money? It's the application that generates the money.
Actually I believe you can do most of the CGI programming in Lisp. But the
success story does not happen because it is Lisp. If YahooStore happens
to use one or more lines of Lisp code, fine. But then?
Why shouldn't you be able to use Lisp for "successful" web sites? Actually
I implemented the code for one in Scheme together with a co-worker.
More important questions are (IMHO):
- Maintainability
- Development cost and time
- Support available
- Acceptance
- Costs and quality of tools
- Solution at the right place at the right time
- ...
If your company doesn't like Lisp and they prefer other solutions,
why force them?
> The preceding paragraph probably shows my own ignorance of the publications
> server. Is there a revenue success story associated with it that is worth
> relaying?
Sure, a company is making money running this web site.
············@ma.ultranet.com writes:
>
> Anybody know which parts of the product are lisp based and which are
> "conventional". [...]
the communications of the acm (may 1998/vol. 41, no. 5) contains the
article "a conversation with paul graham."
in it, graham says:
There is a WYSIWYG editor that lets you edit your site
through a browser. The editor is written in Common Lisp.
The editor uses a C program called WGL to generate images.
When consumers place orders from finished sites, they talk
to the ordering system, also written in C. Finally,
merchants retrieve orders and analyze statistics through
a program called the manager, which is written in perl.
graham makes other remarks which will be unsurprising to readers
of his books, namely that:
the use lexical closures to encapsulate state was indispensible
to the success of viaweb's software, and only lisp
makes closures convenient
bottom-up software development using languages like lisp and perl
which support improvisation enabled viaweb to experiment
and change their minds and their ideas developed
-matt
> Rainer Joswig <······@lavielle.com> wrote:
>
> >·····@norvig.com (Peter norvig) writes:
> >
> >> Paul Graham just sold a Lisp program (and the company built on it) to
> >> Yahoo for $49 million, so after he completes the transition of the
> >> company (in about 2 years), he should have some leisure time to write
> >> some more.
> >
> >Yahoo Store.
> >
> >http://www.viaweb.com/
> >
>
> Dave Tenny
> ············@games.ultranet.com - no spam please
In article <················@nntp.best.com>, ·····@norvig.com (Peter
norvig) wrote:
>I have a short article about the "Learn X in 24 Hours" craze at
>http://www.norvig.com/21-days.html
>
>Paul Graham just sold a Lisp program (and the company built on it) to
>Yahoo for $49 million, so after he completes the transition of the
>company (in about 2 years), he should have some leisure time to write
>some more.
>
>-Peter Norvig
>http://www.norvig.com
>
Good news. (But the following is not my quote.)
>
>>>········@teleport.com (David B. Lamkins) writes:
>>>
>>>Agreed. I don't think anybody here is holding his/her breath for
>>>"Common Lisp for Dummies" or "Learn CL in 24 hours". Another book from
>>>Paul Graham on the other hand...
>>
--
David B. Lamkins <http://www.teleport.com/~dlamkins/>
From: Martti Halminen
Subject: Re: Lisp's Future
Date:
Message-ID: <3592042F.FC0@dpe.fi>
Lieven Marchand wrote:
>
> > This is a matter of opinion, I guess. The CMU AI repository is available
> > on CD-ROM; there's about 5GB -- much of it Lisp source code -- in that
> > collection. The MCL CD-ROM (and the Digitool FTP site) contains well over
> > 100MB of user-contributed code.
>
> Where can you get that CMU AI cd?
I got my copy from Prime Time Freeware, IIRC. It's at home, so can't get
details now.
--
________________________________________________________________
^. Martti Halminen
/ \`. Design Power Europe Oy
/ \ `. Tekniikantie 12, FIN-02150 Espoo, Finland
/\`. \ | Tel:+358 9 4354 2306, Fax:+358 9 455 8575
/__\|___\| ······················@dpe.fi http://www.dpe.fi
Martti Halminen (···@dpe.fi) wrote:
: Lieven Marchand wrote:
: >
: > > This is a matter of opinion, I guess. The CMU AI repository is available
: > > on CD-ROM; there's about 5GB -- much of it Lisp source code -- in that
: > > collection. The MCL CD-ROM (and the Digitool FTP site) contains well over
: > > 100MB of user-contributed code.
: >
: > Where can you get that CMU AI cd?
: I got my copy from Prime Time Freeware, IIRC. It's at home, so can't get
: details now.
The easiest way to get info would probably be PTF's web site:
<http://www.ptf.com/ptf/products/AI/>.
--
Tom Harrington --------- ···@rmii.com -------- http://rainbow.rmii.com/~tph
"Ah, Marie, If you can't trust the governments of the world,
who can you trust?" -"Young Einstein"
Cookie's Revenge: ftp://ftp.rmi.net/pub2/tph/cookie/cookies-revenge.sit.hqx
In article <·························@192.168.0.1>, ········@teleport.com
says...
> Hmm, I guess you're wrong, after all. Unless you mean that no one writes
> Unix shell commands in Lisp. Oops, sorry, I forgot about scsh...
Let's not forget Guile, either. It's small, fast, and easy to integrate
with C code and embed in apps. It's _exactly_ what I need.
--
Please note: my email address is munged; You can never browse enough
"Ahh, aren't they cute" -- Anne Diamond describing drowning dolphins
···@wildcard.this.email.address.intentionally.left.crap.demon.co.uk (Martin Rodgers) writes:
> Let's not forget Guile, either. It's small, fast, and easy to integrate
> with C code and embed in apps. It's _exactly_ what I need.
GUILE is what? Fast and small? Roger, do you realizes that Guile is
the slowest and biggest Scheme interpreter in wider use today? Even
starup time is nothings else than horrible!
Guile has its strengths, but you didn't make a good job to point at
them...
Martin
>>>>> "Martin" == Martin Cracauer <········@waldstrasse.cons.org> writes:
Martin> GUILE is what? Fast and small? Roger, do you realizes that Guile is
Martin> the slowest and biggest Scheme interpreter in wider use today? Even
Martin> starup time is nothings else than horrible!
Wrt. to being slow, isn't `scm', and with that `GUILE', supposed to be
rather efficient in terms of execution speed (i.e. when looking at the
virtual machine performance, not stuff like startup or parsing)?
What other implementations are faster?
[these are honest questions, not an attempt to start yet another flamewar]
---------------------------+--------------------------------------------------
Christian Lynbech | Telebit Communications A/S
Fax: +45 8628 8186 | Fabrik 11, DK-8260 Viby J
Phone: +45 8628 8177 + 28 | email: ···@tbit.dk --- URL: http://www.telebit.dk
---------------------------+--------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)
Christian Lynbech <···@tbit.dk> writes:
> >>>>> "Martin" == Martin Cracauer <········@waldstrasse.cons.org> writes:
>
> Martin> GUILE is what? Fast and small? Roger, do you realizes that Guile is
> Martin> the slowest and biggest Scheme interpreter in wider use today? Even
> Martin> starup time is nothings else than horrible!
>
> Wrt. to being slow, isn't `scm', and with that `GUILE', supposed to be
> rather efficient in terms of execution speed (i.e. when looking at the
> virtual machine performance, not stuff like startup or parsing)?
Yes, it's supposed to be, but they've made enough modifications for
guile & added enough startup baggage (the module system, the debug
system, ...) that it's slower & takes a long time to start up.
> What other implementations are faster?
I wouldn't be surprised if most other implementations are currently
faster. This could change, however, with mods to guile, freezing
startup files, compiling stuff with hobbit, ...
--
Harvey J. Stein
BFM Financial Research
·······@bfr.co.il
In article <·························@192.168.0.1>, ········@teleport.com
(David B. Lamkins) wrote:
[...]
@scsh...
Pardon the dumb question, but what's scsh? I assume it's a shell with
a Lisp interface. Is there comprehensive info on the net?
--
B.B. --I am not a goat!
········@airmail.net (Bryant Brandon) writes:
> Pardon the dumb question, but what's scsh? I assume it's a shell
> with a Lisp interface. Is there comprehensive info on the net?
It's a Scheme shell.
You can get it from <http://www-swiss.ai.mit.edu/scsh/>, where it is
defined thusly:
Scsh is a broad-spectrum systems-programming environment for Unix
embedded in R4RS Scheme.
--
Matt Curtin ········@interhack.net http://www.interhack.net/people/cmcurtin/
In article <······················@www.sprocketshop.com>
·······@pug1.sprocketshop.com (Kenneth P. Turvey) writes:
>
> I have been working with Lisp for something less than a year now, but I
> have grown to really enjoy the language. Unfortunately, it seems that
> the language may not remain usable for many applications for much
> longer. There are several problems with using the language that I would
> like to bring up. If these problems are really non-issues please let
> me know. If the solutions to any of these problems is readily apparent
> please point me in the correct direction.
>
> In this article I am referring strictly to freeware Lisp implementations
> and tools. Although comments about commercial tools and implementations
> are welcome (even requested), I don't think that Lisp's fate will change
> if only commercial tools are available. Unless younger people become
> interested in using the language it will not be in use for most
> applications in just a few years. Most of this market has limited
> funding and will be spending it on tools for C, C++, and Java not Lisp.
>
> I have tried to order these from most to least important, but you may
> have other needs.
>
> 1) There isn't an obvious way to distribute my work in a reasonable
> form. On my Linux box The Free Software Foundation's color ls program
> takes up 37,980 bytes on my disk. In Lisp I can't write and distribute
> a "Hello World" program this small. Is there a way to distribute Lisp
> programs that don't require 10 Meg of disk or more? Would it be
> possible to write an ls program for Linux that required less than 100
> kilobytes and could be distributed as an executable?
>
Take a look at Lpp
http://www.interhack.net/projects/lpp
and see if it can help in any way.
--
William P. Vrotney - ·······@netcom.com
·······@pug1.sprocketshop.com (Kenneth P. Turvey) writes:
> 1) There isn't an obvious way to distribute my work in a reasonable
> form. On my Linux box The Free Software Foundation's color ls program
> takes up 37,980 bytes on my disk. In Lisp I can't write and distribute
> a "Hello World" program this small. Is there a way to distribute Lisp
> programs that don't require 10 Meg of disk or more? Would it be
> possible to write an ls program for Linux that required less than 100
> kilobytes and could be distributed as an executable?
Well, shipping binaries isn't easy, but not really useful, either. The
world isn't just Linux, so the usual form to ship `ls` is as source
with some automatic configure mechanism (autoconf/configure,
imake/xmkmf).
The Lisp equivalent is to supply a single startup file that does the
compile-load-run cycle for a given Lisp implementation.
> 2) There are very few freeware tools available to the lisp programmer
> outside of those that are standard in a lisp system. In C I use DDD to
> debug my code. It is a motif based application that interacts with gdb
> to ease my debugging time. Are tools like this available for Lisp? Are
> there any projects that are currently working on one?
The free Lisp systems lack a good debugger with a friendlier
interface, true.
> 3) The seeming inactivity of the freeware community in the Lisp language
> indicates that many of these problems will persist. It also means that
> the projects that I work on are very unlikely to be written in Lisp.
> There just don't seem to be many freeware projects using lisp.
> Am I wrong here?
Development of CMUCL and Clisp is pushed for some time now and there's
no hint they will run out of steam. Both have several major
contributors (which isn't the case for many Unix freeware tools).
On the other hand, these people mostly add "low-level" features like
concurrency, better compilation and such, not user-friendly things.
> 4) Speed. Lisp is slower than C.
Not as such. If you have enough declarations, several Lisp compilers,
CMUCL amoung them can generate Code that is free from any extra work a
Lisp system typically does:
- Type checking
- Value range checking
- You can get flat arrays wth the elements inline, not arrays of
pointers to the elements.
- allocating new memory. You can make Lisp code operatre in constatnt
space as you can in C. You might not be able to use some standard CL
functions, though.
See www.cons.org/cracauer/ for a small code fragment that does this.
On the other hand:
- Different compilers need different declarations. It may be very hard
to find the right ones and even worse you might have to do implement
entirely different code paths for different compilers.
- CLOS isn't as optimizable.
[...]
> 5) Standardization - The tools available for Lisp don't seem to be
> conforming. I am compiling garnet in the background now. It uses it's
> own version of an object system because CLOS is too slow. I don't mind
> this all that much, but it is a bit annoying. Is CLOS really that slow?
> If so, why? Often I see applications that use special features of the
> Lisp in which they were written. This seems to be much more prevalent
> in the Lisp community than it is in the C/Unix community. Portable code
> seems to be of very limited importance.
CLOS isn't for everyone and everything. Just as Linux, FreeBSD, almost
all of the GNU toolchain (with the exception of groff) and GIMP are
written in C and not C++, many people use plain structs and functions
and are happy with it.
Don't jump on that OO thing too easily. After all, you program a CPU
and that thing doesn't have anything else than functions and data
structures, as seperate things. So using a language with just that may
be *more* intuitive for a knowledgable person.
> 6) Because of the limited number of applications available for lisp
> there seems to be a shortage of sample code. I have seen the Lisp
> repositories and I know about www.cons.org. In comparison to C there
> just don't seem to be that may open source applications for review.
Hm, cons.org is just the CMUCL and Clisp distribution site, besides my
personal one. See the ALU webpages.
> 7) It is more difficult to learn the complexities of the language. It
> is easy to get started, but the learning curve lasts quite some time. I
> guess this is just because it is a big language, but there don't seem to
> be that many places on the web to find assistance... there isn't much out
> there for the intermediate level programmer. There are several fine
> books available, but even these gloss over topics like optimization,
> delivery ( see (1) ), using lisp with other languages, using lisp with
> sockets, using lisp with X, and so on..... Documentation about all of
> these things is available for almost any platform you want to run C on.
I agree. The CMUCL user manual isn't that bad in some of these areas,
though. The CMUCL manual in combination with CMUCL's warning messages
about non-optimal declarations is a good way to start about writing
fast Lisp code.
Martin
·······@pug1.sprocketshop.com (Kenneth P. Turvey) wrote:
[...]
>1) There isn't an obvious way to distribute my work in a reasonable
>form. On my Linux box The Free Software Foundation's color ls program
>takes up 37,980 bytes on my disk. In Lisp I can't write and distribute
>a "Hello World" program this small. Is there a way to distribute Lisp
>programs that don't require 10 Meg of disk or more? Would it be
>possible to write an ls program for Linux that required less than 100
>kilobytes and could be distributed as an executable?
If you're using lisp for something trivial, then you're using the wrong tool,
but that's just my opinion.
Professional lisp systems include runtime system generation.
My most recent use of such a system is Franz' ACLPC 3.0.2 product
for a medium-size application.
The good news is this:
1) There aren't any 10 meg things in sight. The whole ACLPC
compiler/development/gui image is 5MB, so 5.5 MB with the
lisp executable.
2) My application was delivered as a 2.8 MB image, and the 0.5 MB
lisp executable. Compressed it was 880KB for network distribution.
I can live with that, especially with the savings in time I realized to
deliver the application. No royalties were required. Without lisp,
my application wouldn't have happened at all.
The bad news is this:
3) The system generation tool in ACLPC is THE PITS. Horrible
to use. Nevertheless, I managed. Note that ACLPC is
about to be replaced by ACL5, which presumably has better
tools for system generation.
4) The ACL5 runtime generator requires a license unless you're giving your
application away, or unless you reach special agreement with Franz.
They're usually reasonable to talk to, but they're going for more royalties
going forward. Whether it's right is another debate for another topic
(and has been underway elsewhere in this conference).
Overall, if Lisp is the right tool for the job because of the complexity of your
task and the need for delivery or rapid prototyping, then you can ship runtime
images with various vendor products. However 'vendor products' seems to be
another of your concerns, I'll reply below.
>2) There are very few freeware tools available to the lisp programmer
>outside of those that are standard in a lisp system. In C I use DDD to
>debug my code. It is a motif based application that interacts with gdb
>to ease my debugging time. Are tools like this available for Lisp? Are
>there any projects that are currently working on one?
>
>3) The seeming inactivity of the freeware community in the Lisp language
>indicates that many of these problems will persist. It also means that
>the projects that I work on are very unlikely to be written in Lisp.
>There just don't seem to be many freeware projects using lisp.
>Am I wrong here?
If you want free stuff, don't expect good stuff. Perhaps more true in lisp than
other languages because there just isn't that much activity. If you're doing
serious development, the only good lisp (in my opinion), is a supported lisp.
After all, you want to write your application, not debug or extend your lisp.
Unfortunately, market supply and demand is in action. The market has pretty
much done in lisp vendors, and so only a couple remain. That drives up the
price.
Dave Tenny
············@games.ultranet.com - no spam please