There's one thing about LISP that makes it superior to C which
everyone else seems to have missed. For me, this is the major factor
in why Lisp is a much easier language to develop software in. It's
got nothing to do with "AI" (whatever you think it is) or
fancy-schmancy programming environments.
The Big Win is: Storage management in Lisp is a non-issue.
Just about every nontrivial programming task or computer algorithm
involves scarfing up bunches of information the size of which is unknown
until run time. Call them lists, arrays, structures, objects, or what
have you, in Lisp all you have to do is CONS (or MAKE-FOO) them up as
you need them. In C you have to estimate how much memory they'll take
up, figure out how to handle things when they grow bigger than the
memory you've allocated, put in code to barf when the memory isn't
available, etc., etc.
I'd say that a very significant chunk of C programming is devoted to
this pain-in-the-ass storage management stuff. And that's not even
considering the problem of string-building, where you can shoot
yourself in the foot so easily without feeling a thing. When you
write code in Lisp, you can concentrate on the problem to be solved,
not on why the system crashed while you were trying to solve it.
The down side of this, of course, is that storage requirements can
balloon far beyond what is optimally needed, and garbage collection
is necessary. But modern GC technology and clever compilers go a
long way toward mitigating these effects.
Someone on this list said:
>On the other hand, when the problem and its solution are well-defined,
>a language like C is a more likely choice. The code is written, the
>executable delivered, and then set aside until a round of bug fixes.
Point is, that round of bug fixes lasts virtually forever in C, whereas
in Lisp the code is much more likely to be nearly bug-free at delivery.
- SEB
From: Jeff Dalton
Subject: Re: Is this the end of the lisp wave?
Date:
Message-ID: <3969@skye.ed.ac.uk>
In article <··························@MVS.DRAPER.COM> ·······@mvs.draper.com writes:
>The Big Win is: Storage management in Lisp is a non-issue.
It's certainly a big win, but it's not quite a non-issue. For
example, Lisp programmers are often advised to resort to explicit
storage management in order to avoid generating garbage, and some
significant applications have been carefully written so that no
garbage is generated. This is, presumably, less important with
modern "non-intrusive" gc techniques, but I don't think the problem
has yet been reduced to zero.
BTW, I complain about Lisp only because I want it to get better.
I would much rather use Lisp than C, but there are times when I
have to use C because the available Lisps are too big to too slow
for whatever it is I want to do.
>I'd say that a very significant chunk of C programming is devoted to
>this pain-in-the-ass storage management stuff. And that's not even
>considering the problem of string-building, where you can shoot
>yourself in the foot so easily without feeling a thing.
Yes, but C is _much_ faster for such things as readign through
files (or at least it seems to be), in part because one uses
pre-allocated arrays rather than constructing strings. (There's
nothing that prevents similar techniques from being used in Lisp
-- in principal -- but current implementations tend not to provid
it.)
>>On the other hand, when the problem and its solution are well-defined,
>>a language like C is a more likely choice. The code is written, the
>>executable delivered, and then set aside until a round of bug fixes.
>
>Point is, that round of bug fixes lasts virtually forever in C, whereas
>in Lisp the code is much more likely to be nearly bug-free at delivery.
The problem is convincing the right people that this is so. Many
people are used to seeing strong typing as a necessity, or at least
as an important factor in producing reliable code. And Lisp looks
very unsafe to them. (As does C, but for less "pervasive" reasons.)
-- JD
From: Charles Buckley
Subject: Re: Is this the end of the lisp wave?
Date:
Message-ID: <17374@csli.Stanford.EDU>
In article <··························@MVS.DRAPER.COM> ·······@mvs.draper.com writes:
There's one thing about LISP that makes it superior to C which
everyone else seems to have missed. For me, this is the major factor
in why Lisp is a much easier language to develop software in. It's
got nothing to do with "AI" (whatever you think it is) or
fancy-schmancy programming environments.
Finally, here's someone else says: LISP !-> AI
The Big Win is: Storage management in Lisp is a non-issue.
Exact. Makes prototyping a breeze. However, I'd still like to do my
own storage management in Lisp when my algorithm makes that possible
and expedient. It's simply not provided for in CL. A major vendor
who shall remain nameless claims to have no interest in providing for
it as an extension, either. Harumpf. At least Symbolics gave you
with-stack-array (or equiv.).
Solve this and the run-time library logistics, and you'd go a long way
to silencing the Lisp-bashers (at least the ones who speak from
knowledge, as opposed to a simple desire to raise hell).
In article <·····@csli.Stanford.EDU> ···@csli.Stanford.EDU (Charles Buckley) writes:
>Exact. Makes prototyping a breeze. However, I'd still like to do my
>own storage management in Lisp when my algorithm makes that possible
>and expedient. It's simply not provided for in CL. A major vendor
>who shall remain nameless claims to have no interest in providing for
>it as an extension, either. Harumpf. At least Symbolics gave you
>with-stack-array (or equiv.).
I'm not sure precisely what type of extension you're referring to. Both
Symbolics and Lucid provide "resources", which are pools of objects that
can be reused rather than consing new objects each time (I expect Allegro
CL also has resources, but I'm not familiar with its extensions).
The ANSI CL proposal will include a DYNAMIC-EXTENT declaration, which
specifies that the value of the specified variable will only be accessed
within the dynamic extent of the binding form. Compilers can optimize this
into stack allocation of data structures. This is similar to Symbolics's
STACK-LET, and I think Lucid already supports such a declaration.
--
Barry Margolin, Thinking Machines Corp.
······@think.com
{uunet,harvard}!think!barmar
First, this talk about lisp being dead puzzles me. At least in european
academic institutions, it doesn't seem to be dead at all. Quite in
contrary. And among the new lisp installations I have seen on recent
visits to certain universities, are Symbolics lispmachines-on-a-card.
(Alleged problems by Symbolics initiated this discussion, I understand)
Second, why is it claimed that CL is "too big"? What does that mean?
That applications tend to take up much space? That lisp systems take up
much space? Anyway, it is certainly possible to make compact CL systems.
My own favourite system takes up only 790K on my harddisk. And that
includes all of CL (but not yet CLOS) with compiler, editor and
window-interface. In addition there is a 200K documentation system (all
of CL) and 200K of other files. Other programming languages aren't much
better than that. Certain well-known unix CL implementations are much
bigger than this (esp. on RISC machines), which probably is caused by
a "speed first, and leave the space to unix VM"-attitude. Clumsy
solutions wrt. to space is not limited to lisp, however. On one well-
known brand of unix work-stations, the whole X library has to be linked
with any application that uses it, which makes even a small clock a
several-hundred-K application.
However, harddisk (or even RAM) space is not a real problem any more, is
it?
-----------------------------------------
Espen J. Vestre
Department of Mathematics
University of Oslo
P.o. Box 1053 Blindern
N-0316 OSLO 3
NORWAY ·····@math.uio.no
-----------------------------------------
In article <······················@ulrik.uio.no> ·····@math.uio.no (Espen J. Vestre) writes:
>
>However, harddisk (or even RAM) space is not a real problem any more, is
>it?
>
You jest, I presume? Many real applications consume more memory (or disc)
space than current machines tend to have. For example, I used to work on
stereo matching of satellite images - each image was 36 Mb; this would grow
to 144Mb if you used floating point, rather than bytes, for each pixel; and
you wanted to work on a pair at once. Of course, you could chop the images
into pieces - but the ensuing housekeeping & assorted complications considerably
complicated the job. Just while prototyping one (comparatively simple) part of
this job, I had to completely rewrite a C program 3 times to get its size down.
[This wasn't bad planning - I tested the ideas on fragments with simple programs
- then keep refining on more & more realistic data.]
As processors (and cameras) become cheaper and more powerful, such tasks are
likely to become more common ...
Paul
From: Niels Mayer
Subject: Re: Is this the end of the lisp wave?
Date:
Message-ID: <6493@hplabsz.HP.COM>
In article <······················@ulrik.uio.no> ·····@math.uio.no (Espen J. Vestre) writes:
>Second, why is it claimed that CL is "too big"? What does that mean?
>That applications tend to take up much space? That lisp systems take up
>much space? Anyway, it is certainly possible to make compact CL systems.
>My own favourite system takes up only 790K on my harddisk.
How much space a program takes up on a hard disk is not very important
-- disk is relatively cheap compared to RAM. More important, what is
the runtime size of your application? Most of the CL impls I've seen
take up megabytes of valuable RAM and swap space; add a substatial
application on top of that and 10-50 megabyte runtime images become
commonplace. Generally, people won't notice this if you've got a
reasonable amount of RAM and the CL process is the one getting most of
the use. Typical cases for such usage is in application prototyping.
On the other hand, try deliveriing a nontrivial CL-based application
in which the applications is but one of the processes competing for
resources on the workstation. Even worse, try delivering a CL-based
application into a multiuser, multiprocessing environment. You'll be
thrashing like crazy in no time. Users will hate you. Customers will
hate you. RAM manufacturers will be laughing all the way to the bank.
>Clumsy
>solutions wrt. to space is not limited to lisp, however. On one well-
>known brand of unix work-stations, the whole X library has to be linked
>with any application that uses it, which makes even a small clock a
>several-hundred-K application.
The whole X, Xt and widget set library does not need to be linked in
to a X application such as your clock example. Only the parts that
your linker determines is necessary.
However, much more code gets linked in than is ever used. That's
because much of the code needs to be there just incase an
infrequentlly used resource is set, customized, altered-at-runtime,
etc. It's the moral equivalent of having eval linked in to a
deliverable CL program (e.g. there's no way of proving that some
function or functionality can be removed given that data can be
interpreted and executed). Xtoolkit based applications have a
different form of data that can be interpreted -- resources.
I find your comparison of CL against Xtoolkit based applications
interesting due to a particularly warped view of the Xtoolkit that I
hold. Remember that anytime you're using the X toolkit, you are using
the nearest thing to Lisp's inefficiency, but packaged in an all-C
implementation. Everything done in the internals of Xt is dynamic, and
interpreted and very little can be optimized or compiled out at the
level of Xt's C implementation (e.g. Xt's dynamic method lookup).
However, the customizability provided by the Xt implementation makes
applications far more useful, and far easier to integrate into a
variety of work styles and environments. Given shared libraries, and
multiple applications that share the same Xt & widget-set code, the
size of such applications becomes less of a memory burden.
----------
I personally think that Lisp is a wonderful language for prototyping
and extending systems at a high level of abstraction. I also think
that C is a very useful portable assembly language which should be
used when speed and size are important considerations. I use both
languages with equal ease inside WINTERP and I believe that hybrid
programming in both C and Lisp can give you the best of both worlds.
-------------------------------------------------------------------------------
Niels Mayer -- hplabs!mayer -- ·····@hplabs.hp.com
Human-Computer Interaction Department
Hewlett-Packard Laboratories
Palo Alto, CA.
*
Disclaimer: The above opinions are my own, and do not reflect
the official corporate outlook of Hewlett-Packard.
In article <····@hplabsz.HP.COM> ·····@hplabsz.HP.COM (Niels Mayer) writes:
In article <······················@ulrik.uio.no> ·····@math.uio.no (Espen J. Vestre) writes:
>Second, why is it claimed that CL is "too big"? What does that mean?
>That applications tend to take up much space? That lisp systems take up
>much space? Anyway, it is certainly possible to make compact CL systems.
>My own favourite system takes up only 790K on my harddisk.
How much space a program takes up on a hard disk is not very important
-- disk is relatively cheap compared to RAM. More important, what is
the runtime size of your application? Most of the CL impls I've seen
take up megabytes of valuable RAM and swap space.
I believe Espen was referring the Macintosh Common Lisp. The system
(including editor, window system, etc) runs in a memory partition as
small as 1 megabyte. Actually, it runs in 600k if you really want to
push things.
-andrew
disclaimer: I worked/work on this product.
--
From: Jeff Dalton
Subject: Re: Is this the end of the lisp wave?
Date:
Message-ID: <4002@skye.ed.ac.uk>
In article <······················@ulrik.uio.no> ·····@math.uio.no (Espen J. Vestre) writes:
>First, this talk about lisp being dead puzzles me. At least in european
>academic institutions, it doesn't seem to be dead at all.
I don't think Lisp is dead, but I wish it were healthier.
>Second, why is it claimed that CL is "too big"? What does that mean?
>That applications tend to take up much space? That lisp systems take up
>much space?
Both complaints have been made.
>Anyway, it is certainly possible to make compact CL systems.
I agree.
>However, harddisk (or even RAM) space is not a real problem any more, is
>it?
Well, I could certainly use more of both, and my employers don't seem
to be about to buy them for me. The practical consequence in Common
Lisp terms is that I can run KCL on my desk machine but have to put up
with annoying paging delays if I try one of the bigger ones.
-- jeff
From: Charles Buckley
Subject: Re: Is this the end of the lisp wave?
Date:
Message-ID: <17418@csli.Stanford.EDU>
In article <······················@Think.COM> Barry Margolin writes:
In article <·····@csli.Stanford.EDU> Charles Buckley writes:
>Exact. Makes prototyping a breeze. However, I'd still like to do my
>own storage management in Lisp when my algorithm makes that possible
>and expedient. It's simply not provided for in CL.
I'm not sure precisely what type of extension you're referring to. Both
Symbolics and Lucid provide "resources", which are pools of objects that
can be reused rather than consing new objects each time
But resources are nothing more than a sort of software cache of
currently unused objects belonging to an isomorphic class. If you
will, it's a sort of pointer-in-reserve system, to assure that that
which you allocated and might need again doesn't get eaten up
unnecessarily by the gc, just because you don't happen to have
explicitly programmed full pointer coverage for the life of your
algorithm. It's nothing more than a slickered-up version of the hack
that Doug Cutting replied with.
Calling clear-resource only removes all these pointers-in-reserve,
*allowing* the gc to find the freed storage in the course of its own
plodding, methodical ruminations --- this according to language in the
vendor doc, and from my conversation with one of its employees who
should know. If I turn the gc off, calling clear-resource does me no
good - memory still gets exhausted. In those circumstances in which
gc performance is pathologically poor, the resource facility does
nothing to offload it.
I want to be able to tell the gc "I'll let you know when I'm done with
memory, and you should manage the free chunks, consolidating and all
that, but don't bother hunting through memory for non-referenced
blocks." So the above-referenced employee: "That that would
make gc design too hard."
Well, C runtime supports it . . .
In article <·····@csli.Stanford.EDU> ···@csli.Stanford.EDU (Charles Buckley) wrote:
> In article <······················@Think.COM> Barry Margolin writes:
> In article <·····@csli.Stanford.EDU> Charles Buckley writes:
> >Exact. Makes prototyping a breeze. However, I'd still like to do my
> >own storage management in Lisp when my algorithm makes that possible
> >and expedient. It's simply not provided for in CL.
>
> I'm not sure precisely what type of extension you're referring to. Both
> Symbolics and Lucid provide "resources", which are pools of objects that
> can be reused rather than consing new objects each time
>
> But resources are nothing more than a sort of software cache of
> currently unused objects belonging to an isomorphic class. If you
> will, it's a sort of pointer-in-reserve system, to assure that that
> which you allocated and might need again doesn't get eaten up
> unnecessarily by the gc, just because you don't happen to have
> explicitly programmed full pointer coverage for the life of your
> algorithm. It's nothing more than a slickered-up version of the hack
> that Doug Cutting replied with.
>
> Calling clear-resource only removes all these pointers-in-reserve,
> *allowing* the gc to find the freed storage in the course of its own
> plodding, methodical ruminations --- this according to language in the
> vendor doc, and from my conversation with one of its employees who
> should know. If I turn the gc off, calling clear-resource does me no
> good - memory still gets exhausted. In those circumstances in which
> gc performance is pathologically poor, the resource facility does
> nothing to offload it.
>
> I want to be able to tell the gc "I'll let you know when I'm done with
> memory, and you should manage the free chunks, consolidating and all
> that, but don't bother hunting through memory for non-referenced
> blocks." So the above-referenced employee: "That that would
> make gc design too hard."
>
> Well, C runtime supports it . . .
I don't know whether the vendor you are referring to is Lucid, but the
description matches our system. It is true that there is no way for
the user to explicitly return storage to Lisp's free space so that it
can be used without garbage collecting. This is a consequence of the
design of our storage allocator. We could have designed it so that
this operation would be possible, but we felt other factors outweighed
the need for this capability. In fact, many Lisp systems have this
capability. Most such systems manage storage allocation so that
memory returned to the system can only be used for objects of similar
type, or at least of similar size, but that isn't a requirement of
Lisp either.
Broadly speaking, there are two main classes of storage allocation
used by Lisp systems. These are 1) systems that copy all active
objects to new storage and abandon the old storage to be recycled and
2) systems that retain active objects in place and link together
storage used by discarded objects. Systems of the first type are used
by most recent Lisp systems, especially those running on workstations
with virtual memory. C runtime systems (with some exotic exceptions,
such as those running on Lisp machines!) are restricted to the second
type.
The advantages of copying garbage collection include:
- Simpler storage allocation. Allocating a new object is as simple as
incrementing a pointer.
- Avoids fragmentation. Non-copying collectors can cause active
objects to be intermixed with free storage, resulting in difficulty
allocating large objects and increased paging overhead.
- Lifetime-based collection (Generation scavenging or ephemeral GC).
Although it is possible to implement these with non-copying
allocation, they are much simpler and more effective with a copying
GC.
Disadvantages include:
- Copying GC consumes more of the address space, since there must be
space available to copy all active objects. It is for this reason
that copying GC is rarely found on systems without virtual memory,
or those with small address spaces.
- Copying an object requires that you find all pointers to the
object and update them to the new address. In a non-copying system,
it is sufficient to have one pointer to an object, since the pointer
will not change. So-called "conservative" garbage collectors are
generally of this type. Joel Bartlett's "mostly-copying
conservative GC" is a hybrid copying/non-copying system.
- It is difficult to return storage to freespace explicitly in a
copying system.
At the time we designed our system, we felt the advantages outweighed
the disadvantages. The existence of the ephemeral GC means that the
"plodding, methodical ruminations" of the collector usually don't get
in your way.
··@lucid.com Eric Benson
415/329-8400 x5523 Lucid, Inc.
Telex 3791739 LUCID 707 Laurel Street
Fax 415/329-8480 Menlo Park, CA 94025
From: Charles Buckley
Subject: Re: Industrial Strength Lisp GC's (was: end of the lisp wave?)
Date:
Message-ID: <17448@csli.Stanford.EDU>
In article <················@hardwick.lucid.com> ··@lucid.com (Eric Benson) writes:
From: ··@lucid.com (Eric Benson)
Newsgroups: comp.lang.lisp
In article <·····@csli.Stanford.EDU> ···@csli.Stanford.EDU (Charles Buckley) wrote:
<thread about wanting to do my own memory management in Lisp, and
how this isn't possible with a commercial CL offered by a major
vendor. eb is an employee of a major CL vendor>
I don't know whether the vendor you are referring to is Lucid, but the
description matches our system. It is true that there is no way for
the user to explicitly return storage to Lisp's free space so that it
can be used without garbage collecting. This is a consequence of the
design of our storage allocator. We could have designed it so that
this operation would be possible, but we felt other factors outweighed
the need for this capability.
Let's assume it was Lucid, since you confessed, and that's a product
over which you exercise some influence. Anyway, Lucid certainly have
heaps of market share, and therefore can generate lots of garbage (to
collect).
<eb's really succinct and clear review of the state-of-the-art in
commercially available garbage collection deleted, but keeping
back:>
. . . Joel Bartlett's "mostly-copying
conservative GC" is a hybrid copying/non-copying system.
<and>
- It is difficult to return storage to freespace explicitly in a
copying system.
<which Lucid use>
Thanks for a well-written posting on garbage collection. You seem
implicitly to agree that there's still room for improvement in terms
of what's delivered with commercial Lisps, there's some substance
to the many complaints and grumblings, and this is not a time to rest
on one's laurels.
. . . . The existence of the ephemeral GC means that the
"plodding, methodical ruminations" of the collector usually don't get
in your way.
Ah, but making available ephemeral collecting only helps when you're
running things which should ideally be interactive, like communing in
a `terminal-high' with the last cry in these graphics-laden,
memory-hungry, object-oriented universal knowledge representation
schemes so popular of late. Once you start to do serious
calculations, the ephemeral GC becomes ephemeral in effectiveness, and
the time bite the dynamic collector takes can noticeably influence
benchmarks. When its parameters are badly tuned, it can make life
miserable. Not to give the user the opportunity to do his/her own
when s/he knows what to do leads to having Lisp not be taken
seriously.
Anyway, these days, I'd probably combine garbage collection with object
migration among non-shared memory processing nodes on a multi-, which
would really skew your design criteria away from strategies employed
in present-day copying GCs.
In article <··························@MVS.DRAPER.COM> ·······@mvs.draper.com writes:
The Big Win is: Storage management in Lisp is a non-issue.
No, Garbage collectors don't make storage management a non-issue, they
just make it less of an issue (unless you don't care about performance).
In article <·····@csli.Stanford.EDU> ···@csli.Stanford.EDU (Charles Buckley) writes:
However, I'd still like to do my own storage management in Lisp
when my algorithm makes that possible and expedient. It's simply
not provided for in CL.
I'm not sure what you're talking about. One can easily do one's own
storage management in CL. It's not considered exemplary coding style,
but when used judiciously can provide substantial acceleration (e.g.
for long-lived objects under a generation scavenging GC).
(defvar *cons-cells* () "Free list of CONS cells linked by CDR")
(defun make-cell (car cdr)
(let ((cell *cons-cells*))
(cond
(cell
(setq *cons-cells* (cdr *cons-cells*))
(setf (car cell) car)
(setf (cdr cell) cdr)
cell)
(t (cons car cdr)))))
(defun reclaim-cell (cell)
(setf (car cell) nil)
(setf (cdr cell) *cons-cells*)
(setq *cons-cells* cell)
nil)
This could be done with generic functions ALLOCATE and FREE, but this
is not usually needed and adversely affects performance.
Doug
In article <·····················@skye.parc.xerox.com> ·······@parc.xerox.com (Doug Cutting) writes:
>In article <··························@MVS.DRAPER.COM> ·······@mvs.draper.com writes:
>
> The Big Win is: Storage management in Lisp is a non-issue.
>
>No, Garbage collectors don't make storage management a non-issue, they
>just make it less of an issue (unless you don't care about performance).
I suppose the same thing used to be said about virtual memory management.
And about compilation. "It's okay for prototyping, or if you don't care
about performance. But the real thing should be written in assembler."
Perhaps you could do it faster yourself, but hey, life's too short for me
to have to waste my time with bookkeeping details the computer should be
able to handle.
Compilation, virtual memory management, and garbage collection are entirely
mechanical processes, and, as we have already seen in the case of compilers,
computers can become better at them than most programmers.
Kaveh Kardan
Taarna Systems
Montreal, Quebec, Canada
(posting from a friend's account)
In article <·····················@cs.mcgill.ca> ····@cs.mcgill.ca (Dean NEWTON) writes:
In article <·····················@skye.parc.xerox.com> ·······@parc.xerox.com (Doug Cutting) writes:
>No, Garbage collectors don't make storage management a non-issue, they
>just make it less of an issue (unless you don't care about performance).
Compilation, virtual memory management, and garbage collection are entirely
mechanical processes, and, as we have already seen in the case of compilers,
computers can become better at them than most programmers.
This is a naive point of view. Virtual memory does not really provide
infinite, fast, memory. Data structures and algorithms which
acknowlege this can achieve vastly superior performance, e.g. B-trees,
which underly most database systems. Similarly, garbage collectors
cannot always do a satisfactory job of storage management. Usually
they can, but there are programs whose memory usage patterns cause
their performance to become dominated by GC. In these cases one can
often make an otherwise unusable system quite by manual storage
management. A (rather weak) example is the use of RECONS in the PCL
code walker. Sure, PCL will run without it, but your compilations
would run much slower.
To claim otherwise is akin to claims one sometimes hears that memory
usage or CPU speed is no longer an issue. While these are indeed less
of an issue, they're still core concerns of computer science.
Doug
From: Darin Johnson
Subject: Re: Is this the end of the lisp wave?
Date:
Message-ID: <15948@sdcc6.ucsd.edu>
In article <·····@csli.Stanford.EDU> ···@csli.Stanford.EDU (Charles Buckley) writes:
>Finally, here's someone else says: LISP !-> AI
>
> The Big Win is: Storage management in Lisp is a non-issue.
>
>Exact. Makes prototyping a breeze.
OK, I'm another person who likes LISP but doesn't do "AI". Lack of
worry about storage management is nice, but only part of the picture.
What I like is that I don't even have to specify I/O. If I want to
test out an algorithm, I needn't worry about input routines to read
and parse everything or to get things printed back out. This is
especially useful when I want to test a function that isn't the "main"
function. In C I spend lots of time writing wrapper code just to test
functions.
Also, type declaration is optional (until you want to improve
compilation), compilation is optional, etc. So in essence, you can
quickly whip up a program (I don't like the word prototype - sounds
too much like software eng), test it out, and then convert it to C or
something if you need to. (and if you wrote it with the correct
mindset, converting to C is straightforward)
--
Darin Johnson
········@ucsd.edu
- Political correctness is Turing undecidable.
From: John Sambrook
Subject: Re: Is this the end of the lisp wave?
Date:
Message-ID: <5107@amc-gw.amc.com>
[ Warning -- Longish, kind of whiney article ahead :-]
I've been following the "Lisp is dying! / No it's not!" discussion
with interest. I've also had very good experiences using Common Lisp
to develop prototypes of programs that no one would consider "AI"
programs. However, I can also say that I have found Common Lisp useful
for prototyping programs that could be considered to be "AI" programs.
For example, I recently completed a Common Lisp prototype of a memory
disassembler for a new high-performance RISC chip. Of course, for
delivery I had to recode it in C, but I believe that much time was
saved by doing a prototype first. Certainly the delivered version of
the disassembler has been virtually bug-free and is well-structured
and maintainable to boot.
I am also using Common Lisp to experiment with new approaches to trace
disassembly. While I can't explain trace disassembly in detail here,
suffice it to say that it involves correlating a lot of observed data
with a model of how a particular microprocessor behaves in order to
generate an annotated list of the machine instructions that were
executed to produce the observed data. It's a hard problem that
ultimately requires the ability to be able to represent knowledge in a
compact form, and to be able to do a fair amount of reasoning based on
the data and the model. Common Lisp is a great environment in which
to do this. I only wish I had a commercial Common Lisp and CLOS in
which to do this. Right now I am using AKCL on a Solbourne 4-501 with
GNU Emacs. Not bad, but not ideal either. I haven't been able to get
a PCL working though. I have some literature from a couple of the major
Common Lisp vendors, but I doubt that I will be able to secure the
funding to purchase one of their systems.
Unfortunately, there does not seem to be much interest within our
company for looking at programming in any other language than C and/or
assembler. In general, most of our engineers seem to be quite
satisfied with the status quo. While there are a few engineers that
are interested in doing more with Lisp, many of our senior engineers
routinely ignore suggestions to consider using Lisp for certain
problems where Lisp would appear to be a good fit.
I'd be interested in hearing from other individuals who have been able
to introduce Lisp into an engineering environment. While it's not my
role to be a Lisp evangelist, I feel some responsibility to improve
productivity within our company, and I think Lisp would be useful in
this respect.
--
John Sambrook DNS: ····@amc.com
Applied Microsystems Corporation UUCP: amc-gw!john
Redmond, Washington 98073 Dial: (206) 882-2000 ext. 630