efficiency of Lisp compared to other progr. lang.?
Alex Pfister
I was told that compiled Prolog code is on the average about twice
as slow as comparable code written in C, Pascal.
How is the performance of Lisp compared to other programming languages?
--
Alex Pfister e-mail: a.pf...@doc.ic.ac.uk
--
----------------------------------------------------------
Alex Pfister e-mail: a.pf...@doc.ic.ac.uk
Marco Antoniotti
From: ap...@doc.ic.ac.uk (Alex Pfister)
Newsgroups: comp.lang.lisp
Date: 23 Feb 1996 21:46:58 GMT
Organization: Logic Programming Section, Dept of Computing, Imperial College
Lines: 10
Distribution: world
NNTP-Posting-Host: laotzu.doc.ic.ac.uk
I was told that compiled Prolog code is on the average about twice
as slow as comparable code written in C, Pascal.
How is the performance of Lisp compared to other programming languages?
WARNING: FLAME BAIT AHEAD!
About as fast if you use a good compiler as CMUCL (where available).
On the other hand I just read some post elsewhere (was it
comp.lang.dylan ?!?) where ther was somebody complaining that using
the C++ STL slows the system down to about half (well, maybe a bigger
fraction :) ) the speed of a good CL implementation :)
Cheers
--
Marco Antoniotti - Resistente Umano
===============================================================================
International Computer Science Institute | mar...@icsi.berkeley.edu
1947 Center STR, Suite 600 | tel. +1 (510) 643 9153
Berkeley, CA, 94704-1198, USA | +1 (510) 642 4274 x149
===============================================================================
...it is simplicity that is difficult to make.
...e` la semplicita` che e` difficile a farsi.
Bertholdt Brecht
Richard Pitre
> In article <4glcki$l...@frigate.doc.ic.ac.uk> ap...@doc.ic.ac.uk (Alex Pfister)
writes:
>
> From: ap...@doc.ic.ac.uk (Alex Pfister)
> Newsgroups: comp.lang.lisp
> Date: 23 Feb 1996 21:46:58 GMT
> Organization: Logic Programming Section, Dept of Computing, Imperial
College
> Lines: 10
> Distribution: world
> NNTP-Posting-Host: laotzu.doc.ic.ac.uk
>
>
> I was told that compiled Prolog code is on the average about twice
> as slow as comparable code written in C, Pascal.
> How is the performance of Lisp compared to other programming languages?
>
> WARNING: FLAME BAIT AHEAD!
>
> About as fast if you use a good compiler as CMUCL (where available).
> On the other hand I just read some post elsewhere (was it
> comp.lang.dylan ?!?) where ther was somebody complaining that using
> the C++ STL slows the system down to about half (well, maybe a bigger
> fraction :) ) the speed of a good CL implementation :)
>
> Cheers
> --
> Marco Antoniotti - Resistente Umano
>
TAKING THE BAIT
Correct me if I'm wrong about these speed tests but I think that they tend to
be done on C/Pascal turf. If on the other hand the primary data types are
expression trees of indeterminate size and there is pattern matching involved
then, before you get to the speed issue, there is a question in the minds of
many about the availability of C/Pascal programmers who can reliably generate
useful code of this type.
richard
Pete
progr. lang.?>, 'ap...@doc.ic.ac.uk (Alex Pfister)' wrote:
>
>I was told that compiled Prolog code is on the average about twice
>as slow as comparable code written in C, Pascal.
>How is the performance of Lisp compared to other programming languages?
>
system using a reasonable mix of io and computation, Lisp is quite
competitive to other OO systems. It's true that it can't quite match
C++ and other strongly and statically typed languages, in terms of
raw speed, but it's not that far off.
What I think has given Lisp a bad reputation for being slow is
the amount of really beginner-like coding produced. I have seen
many OR and IS types get a two-week crash course on Lisp and
then sit down and start writing a system. These are typically
very intelligent people and they get up to speed quite fast, but
they're not programmers. They often produce good algorithms
for solving AI problems, but the details leave much to be desired.
I have "correctected" many thousands of lines of code like this:
(cond ((equalp "A" (subseq data 0 1)) ...)
((equalp "D" (subseq data 0 1)) ...
Just this last week I dug up an old simulation model where
the programmer had defined:
(defmethod (get-slot-value myflavor) (slot)
(symbol-value-in-instance slot))
and then used (get-slot-value object 'foo) everywhere instead
of calling the accessor functions directly.
-- those who know Symbolics flavors of late 80's may recognize
the syntax, and may also be aware that symbol-value-in-instance
is about 50 times as slow as a direct function call. I could
understand this if the slot names were not known at compile
time, but that wasn't the case. Comments in the code indicated
that the programmer thought he was very clever for having
come up with that scheme.
Anyway, the bottom line is that a properly written Lisp system
can be very fast in operation, and can be developed in less
than half the time required by "ordinary" languages such
as C++.
--
Pete Grant
Kalevi, Inc.
Software Engineering & development
Erik Naggum
| First, assuming skilled and experienced programmers, on a typical
| system using a reasonable mix of io and computation, Lisp is quite
| competitive to other OO systems. It's true that it can't quite match
| C++ and other strongly and statically typed languages, in terms of raw
| speed, but it's not that far off.
is this true? with CMU CL 17f and PCL, I get faster execution, less code,
and faster compilation than I do with C++ and templates using GCC 2.7.2.
if "raw speed" includes programmer time to achieve a working system, Lisp
_cannot_ lose.
#<Erik 3034231713743323>
--
the Internet made me do it
Pete
other progr. lang.?>, 'mar...@lox.icsi.berkeley.edu (Marco Antoniotti)'
wrote:
>WARNING: FLAME BAIT AHEAD!
>
>About as fast if you use a good compiler as CMUCL (where available).
>On the other hand I just read some post elsewhere (was it
>comp.lang.dylan ?!?) where ther was somebody complaining that using
>the C++ STL slows the system down to about half (well, maybe a bigger
>fraction :) ) the speed of a good CL implementation :)
>
believe many Lispers are also C++'ers). All the books and articles I
read about claim how lean and mean it is, but I don't wholeheartedly
agree. When it comes to raw speed, a piece of code written at
a low level, using domain knowledge of the task at hand, nearly
always wins -- templates/generics notwithstanding.
STL is also much more complex to use than "ordinary" class
libraries. Witness all the thick books on the shelves about STL.
But I've decided to start using it since it's part of the standard...
But, to respond to Marco's post, whoever made the complaint is
wrong. Compared to other libraries, STL is generally about as
efficient and fast as its competitors. That it slows the system
down by any noticeable amount is hogwash.
Maybe the claimant is talking about compile times instead. I
can understand why a compiler will have to spend a lot more time
in its job where a large template library is involved. Precompiling
headers should eliminate much of this problem.
is referring to compile times.
Jeffrey Mark Siskind
as slow as comparable code written in C, Pascal.
That depends on lots of factors:
1. Whether or not the C and Lisp versions use the same algorithm.
2. The programming style used in C and Lisp.
3. The type of problem being solved (numeric vs. symbolic vs. ...)
4. The compiler(s) being used.
5. The optimization level settings on the compilers being used.
6. Whether appropriate declarations are given in the Lisp code (if
declarations are allowed)
I have seen Lisp code that runs 35 times slower than C code and I have seen
Lisp code that runs 6 times *faster* than C code. So there is no easy answer
to your question. But I suggest that you take a look a Stalin, a highly
optimizing Scheme compiler available free from my home page. For certain
programs, particularly numeric ones, it generates code that is as good or
better than C, without any declarations.
Jeff (home page http://www.cs.toronto.edu/~qobi)
--
Jeff (home page http://www.cs.toronto.edu/~qobi)
Anthony Berglas
>On Feb 23, 1996 21:46:58 in article <efficiency of Lisp compared to other
>progr. lang.?>, 'ap...@doc.ic.ac.uk (Alex Pfister)' wrote:
>
>
>>
>>I was told that compiled Prolog code is on the average about twice
>>as slow as comparable code written in C, Pascal.
>>How is the performance of Lisp compared to other programming languages?
I did some crude bench marks of Lisp vs C for a simple prime number
generator and a neural net benchmarkk. CMU Lisp actually beat sun and
gnu C for the prime number, probably because it combined a div and mod
operation, and was faster than Sun C and slightly slower than Gnu C
for the nural net.
I think the real speed issue is coding style and the types of programs
you write.
Anthony
--
Anthony Berglas
Rm 312a, Computer Science, Uni of Qld, 4072, Australia.
Uni Ph +61 7 3365 4184, Home 3391 7727, Fax 3365 1999
CSM Lair 3365 1181
Richard A. O'Keefe
>I was told that compiled Prolog code is on the average about twice
>as slow as comparable code written in C, Pascal.
This is meaningless. Compiled by which compiler?
I use several C compilers on this SPARC, and they all have a lot of options,
and it is _easy_ to find a two-to-one speed difference between C compilers.
There are also three C compilers for this machine: p2c+c, pc, gpc, with a
somewhat wider range of speeds.
There are also lots of Prolog compilers. Aquarius Prolog is probably the
top of the line. Prolog compilers vary more than C compilers.
So, which C compiler? What Prolog compiler? What machine?
And most important of all: what program? It is not altogether clear that
there is any such animal as "comparable code written in C", comparable,
that is, to "average" (what's that?) Prolog code. How many C compilers
do well with code that backtracks? How many C compilers are good with
programs that change (not merely are augmented by loading DLLs) at run
time?
You _can_ meaningfully say "THIS compiler for C compiling THIS program
that solves THIS problem generated code that ran THIS fast on THIS
machine, compared with THIS compiler for Prolog compiling THIS program
which took THIS time." Even then, you'll probably find someone saying
"but you've written poor C and worse Prolog; try it like this instead".
>How is the performance of Lisp compared to other programming languages?
Once in order to silence a Lisp-basher I wrote two programs to solve the
same problem. One was written by me in C and was compiled with the
vendor's compiler for an Encore Multimax. The other was written by me
in Scheme and was compiled by the T system, Scheme being a Lisp dialect.
The Scheme version ran 17 times faster.
More recently, I compared a C program compiled by SPARCompiler C and by
gcc with a Scheme version compiled by Stalin. The Stalin code ran faster.
(Surprise! Stalin compiles to C, which is then compiled by GCC.)
--
Election time; but how to get Labor _out_ without letting Liberal _in_?
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.
Martin Cracauer
>In article <s08enrk...@lox.ICSI.Berkeley.EDU>
>mar...@lox.icsi.berkeley.edu (Marco Antoniotti) writes:
>> In article <4glcki$l...@frigate.doc.ic.ac.uk> ap...@doc.ic.ac.uk (Alex Pfister)
>writes:
>>
>> From: ap...@doc.ic.ac.uk (Alex Pfister)
>> I was told that compiled Prolog code is on the average about twice
>> as slow as comparable code written in C, Pascal.
>> How is the performance of Lisp compared to other programming languages?
Good C compilers can produce as overhead-free code as C compilers does.
Two problems:
1) Modern RISC machines needs more than the shortest sequence of
instructions, they need the instructions to be sheduled in a certain
order. Usually, only the compiler writers of the chip makers can
provide optimal sheduling and they usually write C and Fortran
compilers. Even gcc has many problms in this area. Most Lisp
implementations doesn't care about sheduling at all. On Mips
systems I've seen CMUCL producing faster code than gcc for exactly the
same (floating point) algorithm.
The flip side is that a compiler like CMU CL, which has a much higher,
cleaner abstraction of the code generation process may be tuned easier
for such processors than most C compilers. gcc needs a complete new
design of an interafce, some kind of abstraction to provide the
neccessary information about each CPU's preferences. I claim this is
easier to do in Lisp.
2) CL compilers generate good code for build-in data types. But CLOS
types require dynamic lookup. C++ can do static binding and therefore
inlining. This can be a big plus when using small
objects. Additionally, the dynamic lookup of C++ is very efficient,
about twice as fast as that of ObjC (which needs two
indirections). CLOS is much worse. An additional problem is that most
(if not all) CLOS implementations arrange slots using pointers, which
causes one additional access and CPU cache trashing. As I understand,
the required flexibility of CLOS makes it difficult to lay out Slots
as direct values because one needs to be able to redefine the type of
these slots.
The right way might be too look at what Dylan does and see in what way
their sealing type system is useable in a Common Lisp
environment. Would at least require some additional semantics for
packages/modules, I think.
CL can provide good performance but you have to have performance in
mind when you start a project. Most CL programs of mine started as a
very flexible piece of code that has too many dependencies on slow
method lookup in it to change it later.
And don't forget that it requires a good Lisp compiler and a
programmer who understands his compiler. I can't claim to fall into
this category, although I usually get my programs fast enough. In C++
that is not so important.
>> About as fast if you use a good compiler as CMUCL (where available).
>> On the other hand I just read some post elsewhere (was it
>> comp.lang.dylan ?!?) where ther was somebody complaining that using
>> the C++ STL slows the system down to about half (well, maybe a bigger
>> fraction :) ) the speed of a good CL implementation :)
The STL is one of the nicest pieces of C++, IMHO. Used carefully, it
can be very useful to control the performance characteristic of a
program. I'd say "pilot error" or braindead implementation when code
slows down when using STL. Maybe someone could tell them that <MAP> is
not a hashing data type. This alone is the cause of many
slowdowns. People tend to think that a data type such as map is the
fastest possible implementation. Remember that C++ is a language that
is designed by very good people, but that the average user is much
less experienced as members of the Lisp community these days (my
impression).
>Correct me if I'm wrong about these speed tests but I think that they tend to
>be done on C/Pascal turf. If on the other hand the primary data types are
>expression trees of indeterminate size and there is pattern matching involved
>then, before you get to the speed issue, there is a question in the minds of
>many about the availability of C/Pascal programmers who can reliably generate
>useful code of this type.
Right, I think. However, you can get very far with simple data types
when using enough manpower. All this GUI stuff today is implemenated
that way. And it *is* faster than Lisp solutions (CLIM, CLIO, Garnet).
Your argument may be turned against CLOS. Using complex data types in
Common Lisp usually means loosing all support by the compiler, while
C++ doesn't care and produces the same code for "1 + 1" in most cases,
even when expressed as call to an object.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <crac...@wavehh.hanse.de> - Fax +49 40 522 85 36
BSD User Group Hamburg, Germany - No NeXTMail anymore, please.
Copyright 1995. Redistribution via Microsoft Network is prohibited
Richard Pitre
(Martin Cracauer) writes:
> pi...@n5160d.nrl.navy.mil (Richard Pitre) writes:
>
> >Correct me if I'm wrong about these speed tests but I think that they tend
to
> >be done on C/Pascal turf. If on the other hand the primary data types are
> >expression trees of indeterminate size and there is pattern matching
involved
> >then, before you get to the speed issue, there is a question in the minds of
> >many about the availability of C/Pascal programmers who can reliably
generate
> >useful code of this type.
>
> Right, I think. However, you can get very far with simple data types
> when using enough manpower. All this GUI stuff today is implemenated
> that way. And it *is* faster than Lisp solutions (CLIM, CLIO, Garnet).
>
> Your argument may be turned against CLOS. Using complex data types in
> Common Lisp usually means loosing all support by the compiler, while
> C++ doesn't care and produces the same code for "1 + 1" in most cases,
> even when expressed as call to an object.
>
The one-language-for-everything debate is not constructive. My argument will
most certainly be turned against me but then I will stop arguing, shrug, and
make sure that my wallet and my towel are secure. I confess here and now, once
and for all that you CAN do everything in anything, with dime-a-dozen
programmers and its always faster, better, cheaper, more compatible,
politically correct and finally and most importantly doable with compatible
tools that are popular. If someone really believes that they can just as easily
afford to generate and maintain a particular application in C/C++ then, true or
not, that is their financial problem. With enough money you can do it in
assembler. You can really make it cook if you can afford to have a
microcodeable chip made up. I'm sure that a true believer can easily find
significant instances where this was accomplished. Better yet, screw the
microcode, make a chip that is a digital emulation of the problem.
Outside of a few people who put a rediculously high value on their personal
time and who want to actually write code to do something rather than to be a
real CODE WARRIOR(there is actually a product named this), who needs Lisp and
Prolog?
richard
Bill Newman
: In article <s08enrk...@lox.ICSI.Berkeley.EDU>
: > In article <4glcki$l...@frigate.doc.ic.ac.uk> ap...@doc.ic.ac.uk (Alex Pfister)
: writes:
: > I was told that compiled Prolog code is on the average about twice
: > as slow as comparable code written in C, Pascal.
: > How is the performance of Lisp compared to other programming languages?
: > WARNING: FLAME BAIT AHEAD!
: >
: > About as fast if you use a good compiler as CMUCL (where available).
: > On the other hand I just read some post elsewhere (was it
: > comp.lang.dylan ?!?) where ther was somebody complaining that using
: > the C++ STL slows the system down to about half (well, maybe a bigger
: > fraction :) ) the speed of a good CL implementation :)
: > Cheers
: > --
: > Marco Antoniotti - Resistente Umano
: >
: TAKING THE BAIT
: Correct me if I'm wrong about these speed tests but I think that they tend to
: be done on C/Pascal turf. If on the other hand the primary data types are
: expression trees of indeterminate size and there is pattern matching involved
: then, before you get to the speed issue, there is a question in the minds of
: many about the availability of C/Pascal programmers who can reliably generate
: useful code of this type.
: richard
One data point to consider: the world of computer game-playing
programs (programs to play Chess, Go, Bridge, or whatever) seems to be
dominated by programs in C and increasingly C++, with critical parts
hand-coded in assembler where programmer time is available and
portability isn't an issue.
I know something about computer chess (I read the newsgroup..) and I
don't know of any programs not in C, C++, or assembler. (Except that
for a time, CRAY BLITZ used the Cray FORTRAN compiler.)
In Go (my particular interest) expansion trees of indeterminate size
and pattern matching are fundamental, and the three strongest programs
which I'm familiar with (including the current world champion and two other
programs which are almost certainly in the top ten) are
Handtalk (the current world champion and a newcomer this year, written
entirely in 80x86 assembler(!) by a chemistry professor in
mainland China);
Many Faces of Go, written in C by David Fotland at HP; he has said that
it would be in C++ if done today, but it's been around for a decade
or so and that C++ wasn't an attractive option when he started; and
Nemesis, by Bruce Wilcox, who originally wrote
the program in Lisp (as an academic project?) and ended up translating
it to C for efficiency(?) (in the early 1980's?).
These programs tend to represent on the order of 1-10 man-years of
work and perhaps 20K lines of code. Programming efficiency is often
as much of a consideration as run-time efficiency -- Go programmers
tend to play the game *much* better than their programs and have an
abundance of information about the game that they'd teach their
programs if the task could be accomplished in a reasonable amount of
time.
I'm writing my own Go-playing program (not (yet?) one of the strongest
in the world:-). I was sufficiently impressed by some of the rapid
prototyping arguments that I'd seen (and by my own experience with
small Lisp programs) that I wrote an early implementation of my
program in Lisp (actually Scheme, since that seemed like the dialect
with the best support under Linux). However, I ended up abandoning
that approach when I determined that -- for my programming style,
anyway -- it's painful to maintain code without static type checking
once it exceeds 1000 lines or so. (Also (1) I couldn't find a free
Lisp implementation which both had a decent debugger and produced
efficient compiled code (or made it easy to write primitives in C),
and (2) I found that C++ constructors and destructors are a pretty
good conceptual fit to a lot of the things which go on in my program,
and I missed them in my higher-level code.)
I'm now a little skeptical about the competitive advantages that
Richard Pitre describes. My personal experience may have been
distorted by my relative inexperience in Lisp. (I've been programming
in in C, C++, and assembler for more than 15 years, while I've only
spent months programming in Lisp.) For that matter, the relative
scarcity of successful Lisp game-playing programs may reflect the
relative Lisp inexperience of the programmer population at large.
However, the lack of conspicuous success for Lisp programs in this
field does seem to give a sort of upper bound for the competitive
advantage of Lisp as a language to express algorithms to solve this
kind of problem -- especially since one of the top ten programs was
originally written in Lisp. (BTW, I have seen marketing failures and
programmer ignorance cited as explanations for Lisp's relative
obscurity. I submit that if Lisp is just as obscure in direct
machine-to-machine contests as it is in contests mediated by
marketing, media, and purchasing droids, one must wonder about such
explanations..)
Bill Newman
PS. I still like various things about Lisp, and I particularly miss
garbage collection for early prototypes. Once I understand a problem
well enough to do a clean top-down design, C++ makes it it's pretty
easy to do without GC in 90+% of the cases I've run into so far.
However, in one complicated case I ended up writing a 500-line Lisp
prototype before I understood the problem well enough to start my C++
coding..
Fernando D. Mato Mira
|> The STL is one of the nicest pieces of C++, IMHO. Used carefully, it
|> can be very useful to control the performance characteristic of a
|> program. I'd say "pilot error" or braindead implementation when code
|> slows down when using STL. Maybe someone could tell them that <MAP> is
|> not a hashing data type. This alone is the cause of many
|> slowdowns. People tend to think that a data type such as map is the
|> fastest possible implementation.
So, where are the hash tables in STL then? Or is it broken?
Regards,
--
Fernando D. Mato Mira http://ligwww.epfl.ch/matomira.html
Computer Graphics Lab
Swiss Federal Institute of Technology (EPFL) Phone : +41 (21) 693 - 5248
CH-1015 Lausanne FAX : +41 (21) 693 - 5328
Switzerland E-mail : mato...@di.epfl.ch
Richard Pitre
writes:
Affirmation.
Many many good things are written in C and C++ and anything that can be written
can be written in C and C++. I program in C and C++ most of the time. Future
history books will tell a glorious tale of the crucial role played by C and
C++. You can never prove that history would have turned out any better without
them and the books will mostly talk about the huge successes of the victorious.
There is no doubt in my mind that you, Bill Newman, should write all of your
code in C and C++ with time critical parts written in assembler when you can
afford the time. I believe that you should ignore Lisp and Prolog like
languages. Moreover it is mostly a waste of your time, time that can be used
entertaining a C++ parser, to argue with the Lisp and Prolog dinosaur
mentalities.
richard
Erik Naggum
| Outside of a few people who put a rediculously high value on their
| personal time and who want to actually write code to do something
| rather than to be a real CODE WARRIOR, who needs Lisp and Prolog?
some of us still think programming is a form of art.
#<Erik 3034444227283610>
Martin Cracauer
>In article <1996Feb26.1...@wavehh.hanse.de> crac...@wavehh.hanse.de
>(Martin Cracauer) writes:
>> pi...@n5160d.nrl.navy.mil (Richard Pitre) writes:
>>
>> >Correct me if I'm wrong about these speed tests but I think that they tend
>to
>> >be done on C/Pascal turf. If on the other hand the primary data types are
>> >expression trees of indeterminate size and there is pattern matching
>involved
>> >then, before you get to the speed issue, there is a question in the minds of
>> >many about the availability of C/Pascal programmers who can reliably
>generate
>> >useful code of this type.
>>
>> Right, I think. However, you can get very far with simple data types
>> when using enough manpower. All this GUI stuff today is implemenated
>> that way. And it *is* faster than Lisp solutions (CLIM, CLIO, Garnet).
>>
>> Your argument may be turned against CLOS. Using complex data types in
>> Common Lisp usually means loosing all support by the compiler, while
>> C++ doesn't care and produces the same code for "1 + 1" in most cases,
>> even when expressed as call to an object.
>>
>The one-language-for-everything debate is not constructive. My argument will
>most certainly be turned against me but then I will stop arguing, shrug, and
>make sure that my wallet and my towel are secure. I confess here and now, once
>and for all that you CAN do everything in anything, with dime-a-dozen
>programmers and its always faster, better, cheaper, more compatible,
>politically correct and finally and most importantly doable with compatible
>tools that are popular. If someone really believes that they can just as easily
>afford to generate and maintain a particular application in C/C++ then, true or
>not, that is their financial problem. With enough money you can do it in
>assembler. You can really make it cook if you can afford to have a
>microcodeable chip made up. I'm sure that a true believer can easily find
>significant instances where this was accomplished. Better yet, screw the
>microcode, make a chip that is a digital emulation of the problem.
>Outside of a few people who put a rediculously high value on their personal
>time and who want to actually write code to do something rather than to be a
>real CODE WARRIOR(there is actually a product named this), who needs Lisp and
>Prolog?
I hope you didn't misunderstand me. Of course I don't advocate the
skillless programming tendencies widespread today. And actually use
Lisp for some projects I get payed for. Nothingtheless, some problems
in Lisp cause trouble for me.
ken
>>
the lack of conspicuous success for Lisp programs in this
field does seem to give a sort of upper bound for the competitive
advantage of Lisp as a language to express algorithms to solve this
kind of problem
<<
OK, but I think that is what some early posts were saying. In "this
field" for "this kind of problem" ... sure. For chess, go and checkers
the "squares", pieces are all represented as simple integers. Plus to do
a good job you have to sample a kazillion possibilities. I am a recent
convert to Lisp and know for a fact it is the best programming language
ever made, but when I ask myself where I would not use it, I always
think of Chess (or for image transformations done by PhotoShop).
William Ware
: ... if we had a language independent standard for
: module linkeage then some of the problems with selecting an appropriate
: language for a project would vanish overnight...
I think this is the idea behind Guile (Cygnus Support) and ILU (Xerox PARC).
Here are relevant some web pointers.
ILU <ftp://ftp.parc.xerox.com/pub/ilu/ilu.html>
Guile <http://www.cygnus.com/library/ctr/guile.html>
<http://nis-www.lanl.gov/~rosalia/gnudl-doc/learn_libguile_toc.html>