OFF-TOPIC:: Why Lisp is not my favorite programming language
nobody
asked me to detail my opinion of Lisp, and for the benefit
of people like him, who may find themselves intrigued by
this language.
The opinions expressed herein are my personal ones, coming
from several years of experience with Lisp. I did plenty of
AI programming back in the day, which is what would now be
called "search" instead.
Due to time constraints, I will refrain from posting any
follow-ups here. Participants of other newsgroups are well
aware of comp.lang.lispers' tendency to engage in personal
attacks, so a productive discussion with them is unlikely
anyway.
Permission is granted to copy and distribute this document
without restrictions.
=========================================================
Why Lisp is not my favorite programming language.
=========================================================
(In the following, "Lisp" refers to ANSI Common Lisp)
This article is a collection of facts anyone interested in
Lisp should know about.
---------------------------------------------------------
FACT 1: The fastest Lisp implementations are slow
(See any third-party benchmark: The Great Computer Language
Shootout comes to mind, but the Coyote Culch test is in my
optinion even better: it is a professional-quality
interlanguage benchmark)
As a rule of thumb, the most hand-optimized Lisp programs
will be longer than their C/C++ equivalents, and will run
2-20 times slower using the best compilers.
This alone is half the truth. To get such performance out
of Lisp, one has to add type declarations and shed all
safety checks, which is analogous to casting /everything/
to (void*) in C. This is needed to turn off type tag checks
at run time.
Sadly, Lisp code that was posted to USENET by Pascal
Bourguignon for the Coyote Gulch test did not measure up
even to these low expectations and was 31.6 times slower
than C++, using CMUCL 18d as a Lisp compiler and Intel C++
7.1 (with -O3 -xW optimization switches) as a C++ compiler
on Pentium IV.
---------------------------------------------------------
FACT 2: No one but a small clique of fanatics likes it
No matter how odd or perverted the cause, there will be
followers. In fact, the odder the cause, the fewer, but
more fervent its followers are. Look at any religious cult,
like Scientology, or take a peek in comp.lang.lisp and
listen to Lisp zealots talk about 'making sacrifices for
the cause' (in all seriousness!). Look up "a public
apology" thread started by Pascal Costanza as an excellent
example.
ZEALOTS STOP AT NOTHING TO ADVANCE THEIR CAUSE, AND
PERSONALLY ATTACKING ANYONE WITH A DISSENTING OPTINION IS
THE FIRST THING IN THEIR ARSENAL.
---------------------------------------------------------
FACT 3: The vast majority of people who study Lisp in
school, never want to use it again.
You should already know this if you studied or taught CS
where Lisp courses were offered. Even those students who
are fond of Scheme are usually disgusted by Lisp.
---------------------------------------------------------
FACT 4: Lisp is the most complicated language in the world
It has the biggest standard specification document, which
is also the most obfuscated one - something a lawyer
pretending to be a programmer could have written. C, C++
and Fortran 95 specs are much better written, by people who
can communicate directly and eloquently.
---------------------------------------------------------
FACT 5: Despite its size, Lisp does not define threads or
GUI.
Large libraries are very useful when programming, however
Lisp's many functions and macros hardly qualify.
---------------------------------------------------------
FACT 6: There is no open-source cross-platform native-code
compiler
It was suggested that GCL (GNU Common Lisp) is the only
exception. However, it needs to be noted, that despite its
name, GCL is a dialect of its own, is quite slow even by
Lisp standards, and most alarmingly, unlike with other
compilers, its license requires your, programmer, code to
be GPL if you distribute it with GCL. (Because you will
need to use GCL both as a compiler and a run time library)
---------------------------------------------------------
FACT 7: There is no standard C interface.
C has become a lingua franca for interlanguage APIs. It may
be unfair, but not having a standard C interface is a
serious problem for any language.
EPILOGUE:
I do not hate Lisp, and I think it was a fine tool decades
ago, and I am not going to say "Lisp sucks". However, now
that we have superior languages for coding close to the
iron, high-performance computing, number crunching,
algorithms, scripting and gluing components together, Lisp
should be finally retired.
Matthias Felleisen
> EPILOGUE:
>
> I do not hate Lisp, and I think it was a fine tool decades
> ago, and I am not going to say "Lisp sucks". However, now
> that we have superior languages for coding close to the
> iron, high-performance computing, number crunching,
> algorithms, scripting and gluing components together, Lisp
> should be finally retired.
somebody answers:
Lisp has been declared dead for the past N years. Unlike Algol, Simula 67, PL/I,
Pascal, ... and many more languages that came and went, it is still alife and
kicking. It will be alive and fun to program in for many years to come, because
it still has many advantages over C#, Java, Perl, Python, Ruby, and many other
languages that *will* come and go before Lisp is truly retired.
Long live Scheme
And now it's time to go back and strengthen Scheme even more.
-- Matthias Felleisen, PLT
Christopher Benson-Manica
^^^^^^^^^^^
> This article is posted at the request of C.W. Yang who
> asked me to detail my opinion of Lisp, and for the benefit
> of people like him, who may find themselves intrigued by
> this language.
Wow, isn't that nice of you to post for Mr. Yang. I'm sure I, like
everyone on comp.lang.c, is utterly fascinated by Lisp and Mr. Yang's
critique of it. Likewise, I'm sure, for the happy inhabitants of
comp.lang.c++, comp.lang.java.programmer, and comp.lang.python.
Followups set, anonymous crossposting troll.
> ---------------------------------------------------------
> ---------------------------------------------------------
> ---------------------------------------------------------
> ---------------------------------------------------------
> ---------------------------------------------------------
> ---------------------------------------------------------
> ---------------------------------------------------------
> EPILOGUE:
--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
(blank lines added below to keep my newsreader happy)
Thomas Weidenfeller
> This article is posted at the request of C.W. Yang who
> asked me to detail my opinion of Lisp, and for the benefit
> of people like him, who may find themselves intrigued by
> this language.
You should be shot on sight for posting advocacy to a bunch of
non-advocacy groups. "Thanks" for polluting the groups with yet another
programming language war.
F'up set.
/Thomas
Joe Marshall
> This article is posted at the request of C.W. Yang who
> asked me to detail my opinion of Lisp, and for the benefit
> of people like him, who may find themselves intrigued by
> this language.
Did he ask you to post this article in these newsgroups?
comp.lang.c++
comp.lang.java.programmer
comp.lang.scheme
comp.lang.c
comp.lang.python
Why did you not post it comp.lang.lisp where it would be at least
relevant?
> Due to time constraints, I will refrain from posting any
> follow-ups here.
If you do not intend to engage in convesation, why are you posting it?
> This article is a collection of facts anyone interested in
> Lisp should know about.
Is there some reason anyone should take `nobody' at yahoo seriously?
> Look up "a public apology" thread started by Pascal Costanza as an
> excellent example.
What does such a personal matter have to do with the language?
> I do not hate Lisp, and I think it was a fine tool decades
> ago, and I am not going to say "Lisp sucks". However, now
> that we have superior languages for coding close to the
> iron, high-performance computing, number crunching,
> algorithms, scripting and gluing components together, Lisp
> should be finally retired.
You clearly have some sort of axe to grind. If you don't like Lisp,
don't use it.
To others, if you are unfamiliar with Lisp you are welcome to read a
rebuttal in comp.lang.lisp
Please direct all followups to comp.lang.lisp
Ray Dillinger
>
> This article is posted at the request of C.W. Yang who
> asked me to detail my opinion of Lisp, and for the benefit
> of people like him, who may find themselves intrigued by
> this language.
>
The solution to your problem is obvious. Just treat Lisp like
Chocolate; if you don't like it, you can't have any.
Followups set.
Bear
Guillaume
This was pretty funny nonetheless.
As for me, I would say practically the same things about Java. :-p
Kaz Kylheku
> FACT 2: No one but a small clique of fanatics likes it
>
> No matter how odd or perverted the cause, there will be
> followers. In fact, the odder the cause, the fewer, but
> more fervent its followers are.
But nobody is more fervent than lunatics whose membership applications
were *rejected* by imaginary little fanatic cliques. Their cause, in
fact, usually has just one follower.
Martin Ambuhl
> This article is posted at the request of C.W. Yang who
> asked me to detail my opinion of Lisp, and for the benefit
> of people like him, who may find themselves intrigued by
> this language.
I fail to see why anyone should give a rat's ass about what someone
hiding behind "nobody_u_...@yahoo.com (nobody)" has to say about
anything. "Nobody"'s opinions about LISP, C, or the color of bananas is
completely worthless. When you have the cajones to stand behind your
opinions, you might be paid attention to.
E. Robert Tisdale
[snip]
This is an obvious troll. Please ignore it.
Dale King
news:c24nh3$9it$1...@camelot.ccs.neu.edu...
> nobody wrote:
>
> Lisp has been declared dead for the past N years. Unlike Algol, Simula 67,
PL/I,
> Pascal, ... and many more languages that came and went, it is still alife
and
> kicking.
I really am not getting into the debate over lisp, but the notion that those
other languages are dead is not correct. I'm not sure there is a successful
language invented that has ever truly died. Interest in Simula for example
keeps growing. There is an annual conference for Simula and the attendance
grows every year.
I would bet that there is somebody somewhere still programming in ENIAC
assembly language.
Feel free to name a language that you think is dead and someone will tell
you someplace that it is still in active use.
--
Dale King
Jorge Rivera
> As for me, I would say practically the same things about Java. :-p
>
Wow, you are comparing a fairly useless language (Lisp) with a powerful
and flexible languange (Java), and would come up with the same arguments
as to why it sucks?
Not that I really care, it is just interesting how your preconceived
notions of Java blind you...
Greg Ewing (using news.cis.dfn.de)
> I would bet that there is somebody somewhere still programming in ENIAC
> assembly language.
Did ENIAC *have* an assembler? I thought it was programmed
with a patch panel.
(The word "patch" meant something quite different in those
days...)
--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg
Jon A. Cruz
>>
>> As for me, I would say practically the same things about Java. :-p
>>
>
> Wow, you are comparing a fairly useless language (Lisp) with a powerful
> and flexible languange (Java), and would come up with the same arguments
> as to why it sucks?
Well, I happen to use that "fairly useless" language daily in working
with Java.
:-)
(Sorry, guys. Couldn't resist)
David Shaw
- David
// http://david.artoo.net/
Joe Marshall
> Feel free to name a language that you think is dead and someone will tell
> you someplace that it is still in active use.
Focal
FX
Lakota
REBOL 1.x
Mike Nishizawa
you hold that 1 language is better than all other languages, then you
ARE ignorant. LISP is a parsing language. It's obviously not made to
do the same things that C is. LISP is extremely fast for processing
data files.
C in not an end-all be-all of programming languages, even though it is
quite robust. For instance, C is great if you are going to develop
software for 1 platform. However, if you are developing software for
multiple platforms, Java is a better choice.
Really these discussions boil down to the programmer him/herself, who
is usually the one at fault for poor performance. I'm not quite sure
when this happened, but at some point programmers started relying on
hardware for fast, efficient software and from that point on, the
quality and emphasis placed on writing efficient programs has
diminished. If you want your code to run faster, make it more
efficient... make it use less resources... and use the right language
for the job. Don't try to fit all things under one umbrella because
that language has not been developed yet.
Guillaume <grsN...@NO-SPAMmail.com> wrote in message news:<40460dd5$0$5916$7a62...@news.club-internet.fr>...
Guillaume
> with Java.
Hehe, nice. ;-)
Tom Lord
>
> Really these discussions boil down to the programmer him/herself, who
> is usually the one at fault for poor performance. I'm not quite sure
> when this happened, but at some point programmers started relying on
> hardware for fast, efficient software and from that point on, the
> quality and emphasis placed on writing efficient programs has
> diminished.
The first time I heard someone say something like that it was 1987
and, at that time, it was already a tired old cliche.
That doesn't make it exactly false but the reality is, of course,
a usually unsolvable equation of hardware costs and programmer costs,
projected forward in time over the anticipated lifetime of the project.
"Efficient", in the broader sense, is only partly a function of
computing
resources consumed. Sometimes programmers are quite right to rely on
hw to cover their cycle-wasting sins.
Part of my hope/presumption regarding lisp performance -- even for
fairly
naive implementations -- is that as hw continues to get hairier and
compilers/morphers to take advantage of that fancier, the differences
between
HLL's and, say, C will mostly evaporate because, hey, your typical C
code
doesn't know what to do with all that extra power. Who needs a lisp
machine? You've already got one.
-t
Jacek Generowicz
> These posts are like big huge neon signs that say, "I'm IGNORANT."
He then goes on to say.
> LISP is a parsing language.
Thereby creating a self referential articrle.
Tim Daneliuk
> These posts are like big huge neon signs that say, "I'm IGNORANT." If
> you hold that 1 language is better than all other languages, then you
> ARE ignorant. LISP is a parsing language. It's obviously not made to
> do the same things that C is. LISP is extremely fast for processing
> data files.
>
> C in not an end-all be-all of programming languages, even though it is
> quite robust. For instance, C is great if you are going to develop
> software for 1 platform. However, if you are developing software for
> multiple platforms, Java is a better choice.
>
> Really these discussions boil down to the programmer him/herself, who
> is usually the one at fault for poor performance. I'm not quite sure
> when this happened, but at some point programmers started relying on
> hardware for fast, efficient software and from that point on, the
> quality and emphasis placed on writing efficient programs has
> diminished. If you want your code to run faster, make it more
> efficient... make it use less resources... and use the right language
> for the job. Don't try to fit all things under one umbrella because
> that language has not been developed yet.
>
http://www.tundraware.com/Technology/How-To-Pick-A-Programming-Language/
----------------------------------------------------------------------------
Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/
Matthias
> Part of my hope/presumption regarding lisp performance -- even for
> fairly naive implementations -- is that as hw continues to get
> hairier and compilers/morphers to take advantage of that fancier,
> the differences between HLL's and, say, C will mostly evaporate
> because, hey, your typical C code doesn't know what to do with all
> that extra power. Who needs a lisp machine? You've already got
> one.
The hardware vendors invest quite a lot of money and thought into
developing efficient compilers for C, C++, FORTRAN (sometimes). And
vice versa, they build their hardware so that efficient code can be
compiled for it. This is not going to change too soon.
But then: That performance penalty you might face when coding in a
decent lisp implementation instead of in C _definitely_ does _not_
explain, why lisp is not as frequently used as other languages: Java,
Perl, Python, Ruby are much slower than lisp in most cases and people
do not seem to be overly bothered.
So, in my opinion, the "slowness of lisp" is a much-discussed non-issue.
goose
please dont top-post.
tia.
> These posts are like big huge neon signs that say, "I'm IGNORANT."
So is the post I am now responding to!
At the risk of offending you, are you sure that your last 3 years
as a programmer have properly equipped you to make informed
decisions like the ones you've made below?
<snipped>
> quite robust. For instance, C is great if you are going to develop
> software for 1 platform. However, if you are developing software for
> multiple platforms, Java is a better choice.
Pick a fairly simple application ... lets say a tic-tac-toe
game. Are you certain that the game implemented in java will
run on more platforms than the same game implemented in ANSI
C?
C has many many weaknesses; platform dependence is /not/ one of
them.
<snipped stuff I am in agreement with>
goose,
Ray Dillinger
>
> This article is posted at the request of C.W. Yang who
> asked me to detail my opinion of Lisp, and for the benefit
> of people like him, who may find themselves intrigued by
> this language.
>
The solution to your problem is obvious. Just treat Lisp like
Michael Borgwardt
>>quite robust. For instance, C is great if you are going to develop
>>software for 1 platform. However, if you are developing software for
>>multiple platforms, Java is a better choice.
>
>
> Pick a fairly simple application ... lets say a tic-tac-toe
> game. Are you certain that the game implemented in java will
> run on more platforms than the same game implemented in ANSI
> C?
Absolutely certain if it uses a GUI. Otherwise, it depends very much
on the C programmer, whereas even the most incompetent Java programmer
will find it hard to casually insert a platform dependance.
> C has many many weaknesses; platform dependence is /not/ one of
> them.
Like *hell* it isn't!
- sizes of basic types differ between platforms and compilers
- newly allocated memory may or may not be zeroed
- sctructs may or may not be padded, variables may or may
not need to be aligned
- etc.
Yes, you can work around all of them, but it takes an active effort. There's
a reason why it's now common practice to buld C applications with GNU
autoconf, making the build a *three*-level process (counting pre-processor,
compilation and linking together as only one). And it still often fails
with cryptic error messages.
Yuri Schaeffer
I'm trying to write a news server and did some test with a random header
I found in this group. But I forgot to set newsgroups to a test group...
So the above is not a repost, just my garbage. It also was a crosspost,
that does make me realy bad doesn't it? ;)
(sorry)
yuri
Tom Lord
> Tom Lord <lo...@regexps.com> writes:
> > Part of my hope/presumption regarding lisp performance -- even for
> > fairly naive implementations -- is that as hw continues to get
> > hairier and compilers/morphers to take advantage of that fancier,
> > the differences between HLL's and, say, C will mostly evaporate
> > because, hey, your typical C code doesn't know what to do with all
> > that extra power. Who needs a lisp machine? You've already got
> > one.
> The hardware vendors invest quite a lot of money and thought into
> developing efficient compilers for C, C++, FORTRAN (sometimes). And
> vice versa, they build their hardware so that efficient code can be
> compiled for it. This is not going to change too soon.
What's the bug in this line of reasoning?:
1) A substantial part of the overhead of a HLL, especially
one with run-time type checking, doesn't introduce data
dependencies on code doing the actual computation. You
can do things like type checking in parallel while speculatively
running the instructions that are taken if the type check
passes. My intuition is that typical C programs won't be able
to exploit that level of parallelism.
2) HW designers are likely to design for that parallelism anyway
both for particular classes of algorithm (maybe graphics or
sound processing) and, exactly to make HLL's run faster.
In the limit, the kinds of things that custom lisp hardware would
do in parallel wind up being done on stock hardware, in parallel.
I admit it's just a guess but is it a really _bad_ guess?
> But then: That performance penalty you might face when coding in a
> decent lisp implementation instead of in C _definitely_ does _not_
> explain, why lisp is not as frequently used as other languages: Java,
> Perl, Python, Ruby are much slower than lisp in most cases and people
> do not seem to be overly bothered.
> So, in my opinion, the "slowness of lisp" is a much-discussed non-issue.
Sure -- I don't mean to fuel performance myths.
-t
Dale King
news:smgolj...@ccs.neu.edu...
> "Dale King" <kingd[at]tmicha[dot]net> writes:
>
> > Feel free to name a language that you think is dead and someone will
tell
> > you someplace that it is still in active use.
> FX
I forgot to qualify this statement like I did another in my post. It only
applies to languages that actually were successful languages. Many languages
have been invented that never actually really "lived" in that they were not
widely known. FX seems to fall in this category. It appears to only be an
MIT research project.
> Focal
Can't testify to its use, but I find information about it on the web.
> Lakota
I can't speak to this one as there is almost no information on the web. Not
sure if it ever was successful.
> REBOL 1.x
And the fact that a language involves from one version to another does not
qualify as the language being dead. REBOL seems to be far from dead:
Bootstrap Bill
"Dale King" <kingd[at]tmicha[dot]net> wrote in message
news:4046...@news.tce.com...
> Feel free to name a language that you think is dead and someone will tell
> you someplace that it is still in active use.
Radio Shack Level I BASIC?
Claudio Puviani
Nope. I have a TRS-80 Model I with Level I BASIC in my mini-museum. Granted, the
only "use" is to show friends that it still works, but it's still a form of use.
:-)
Claudio Puviani
Nick Landsberg
Bootstrap Bill wrote:
MAD? (AKA - Michigan Algorithmic Decoder)
--
Ñ
"It is impossible to make anything foolproof because fools are so
ingenious" - A. Bloch
Abdulaziz Ghuloum
(in message <smgolj...@ccs.neu.edu>):
At IU, we use Focal in the digital design course to stress-test our
hand-built PDP8s.
Aziz,,,
Bootstrap Bill
"Claudio Puviani" <puv...@hotmail.com> wrote in message
news:lo23c.34147$Ak2.10...@news4.srv.hcvlny.cv.net...
BASIC, cassette tape for storage. It was several years before I could afford
a system with a floppy drive, let alone a hard drive.. I spent nearly all my
free time for months teaching myself BASIC programing, mostly trial and
error. The book that came with my Model I was a great introduction to
programming.
My 13 year old niece wants to learn programming. What's the best
introductory language for her?
Russell Wallace
<wrco...@yahoo.com> wrote:
>I was 15 when I got my first computer, a 4k TRS-80 Model I with Level I
>BASIC, cassette tape for storage. It was several years before I could afford
>a system with a floppy drive, let alone a hard drive.. I spent nearly all my
>free time for months teaching myself BASIC programing, mostly trial and
>error. The book that came with my Model I was a great introduction to
>programming.
Those were the days ^.^
>My 13 year old niece wants to learn programming. What's the best
>introductory language for her?
I'd recommend Python as a good introductory language - easy,
intuitive, but definitely not dumbed down.
--
"Sore wa himitsu desu."
To reply by email, remove
the small snack from address.
http://www.esatclear.ie/~rwallace
Gernot
from GLBasic.com.
qed.
Gernot Frisch.
"Russell Wallace" <wallacet...@eircom.net> schrieb im Newsbeitrag
news:405ef463...@news.eircom.net...
Minti
> you hold that 1 language is better than all other languages, then you
> ARE ignorant. LISP is a parsing language. It's obviously not made to
> do the same things that C is. LISP is extremely fast for processing
> data files.
>
> C in not an end-all be-all of programming languages, even though it is
> quite robust. For instance, C is great if you are going to develop
> software for 1 platform. However, if you are developing software for
> multiple platforms, Java is a better choice.
>
> Really these discussions boil down to the programmer him/herself, who
> is usually the one at fault for poor performance. I'm not quite sure
> when this happened, but at some point programmers started relying on
> hardware for fast, efficient software and from that point on, the
> quality and emphasis placed on writing efficient programs has
> diminished. If you want your code to run faster, make it more
> efficient... make it use less resources... and use the right language
> for the job. Don't try to fit all things under one umbrella because
> that language has not been developed yet.
>
Quite valid arguments. However I have one question to ask, I am quite
naive with LISP { just couple of weekends ) but I think the OP did
raise some doubts in my mind. I mean to me LISP looks right now to be
just OK. Some people said that with all the () it is difficult to code
in but I think that with proper indentation that is absolutely
ludicurous. However when some one says that the code might be 31.?
times slower as compared to C, kinda of scares me. Could assert such
figures. I know speed is not the one and only goal but just wondering
if these figures are correct.
Thanks
--
ISA
ikaur at acm dot org
Replace "kaur" by "singh"
Joe Marshall
> Some people said that with all the () it is difficult to code
> in but I think that with proper indentation that is absolutely
> ludicurous. However when some one says that the code might be 31.?
> times slower as compared to C, kinda of scares me. Could assert such
> figures. I know speed is not the one and only goal but just wondering
> if these figures are correct.
With the wrong algorithm, a naive piece of lisp code can be several
thousand times slower than the `equivalent' C code.
On the other hand, with partial evaluation and a good compiler a piece
of lisp code can be quite a bit faster than the `equivalent' C code.
--
~jrm
Roger Binns
> times slower as compared to C, kinda of scares me. Could assert such
> figures. I know speed is not the one and only goal but just wondering
> if these figures are correct.
It will depend on what you are doing. Every language has a sweet spot
and/or data structures that it is very efficient at. For most, much
of the runtime library is implemented in C, and so the only difference
between the languages is how many instructions it takes to go from
the language into the C library. There are also pathological examples
of poor performance in all languages.
The thing you should look at most is programmer productivity. Consider
the following two scenarios:
- Product A is developed in 6 months, 6 months is spent testing etc
and then shipped/used for 6 months.
- Product B is developed in 18 months, with minimal testing time.
If the products are identical in function, but product A is a quarter
of the speed of product B, which would you prefer? Don't forget that in
18 months the speed of the average computer doubles.
Even though A is slower, you will have been getting results for
more than 6 months before B is ready.
It is also a fallacy that you have to use one language. You
can normally fairly easily run multiple languages in the same
process by embedding interpretters and/or providing extension
libraries.
The answer is pick the best tool for the job, and in most cases
programmer productivity is of great importance. You can try and
optimise program resources (memory, cpu) early on, but it usually
isn't worth it. You can work on them later (by coding extensions
in a lower level language), or buy more hardware with the money
and time you have saved by getting something working sooner.
Roger
Ng Pheng Siong
> However when some one says that the code might be 31.?
> times slower as compared to C, kinda of scares me. Could assert such
> figures. I know speed is not the one and only goal but just wondering
> if these figures are correct.
Recently, some troll challenged c.l.lisp:
"The best known non-stupid (real problem, any algorithm) benchmark is
probably the Coyote Gulch test. There are many languages that it has been
translated into. If you can produce (write or find) and post a Lisp version
that is within 10% of C performance, I will admit that #1 is incorrect."
http://home.comcast.net/~bc19191/blog/040308.html
--
Ng Pheng Siong <ng...@netmemetic.com>
http://firewall.rulemaker.net -+- Firewall Change Management & Version Control
http://sandbox.rulemaker.net/ngps -+- Open Source Python Crypto & SSL
Mike Nishizawa
I would ask what the C program is doing. If it beats LISP at it's own
game which is, list processing, then that would be different. I don't
think I would choose to write an enterprise application in it, but I
think it's as good a choice as anything for any type of parsing
applications. And to the smart guy who feels like he can take a stab
at me for calling lisp a parsing language... consider: a parser is,
by definition, something that analyzes or separates (input, for
example) into more easily processed components. Let's take a
document, for instance. If I wanted to parse the document and
separate it into words, I would write a parser to do so. What is a
document but a list of words separated by spaces... an especially good
application for a LISt Processing language.
Jacek Generowicz
> If it beats LISP at it's own game which is, list processing,
> an especially good application for a LISt Processing language.
[lots more uninformed garbage elided]
Please get a clue about what Lisp is in the 21st century (hell, even
what it was in the last 2 decades of the 20th century), before posting
any more of your drivel.
For example, you could look at http://franz.com/success/ for a little
insight into what is being done (mereyly by processing lists and
parsing files, according to your view of the world) in Lisp today.
Mike Nishizawa
2 words pal, settle down. If you weren't such a fanatic you would
realize that we are not not saying anything that different. I have
simply used a different, more simple example. I learned AI
development with LISP. I have used it in web applications in the
past. I realize that it is used for more advanced applications and I
am not limiting the functionality of it to a parser. I am saying that
it's native functionality is list processing and had to defend my
earlier position that it makes it good for parsing files because you
seem to want to zealously attack me if I don't present LISP in it's
greatest possible light.
The original point of the post was simply to say one language is the
best for all applications is stupid. If you plan to develop
something, choose the language that it is most suited to solving the
problem instead of trying to say that EVERYTHING from drivers to
enterprise applications should be developed in one language. If I had
known you were out there ready to pounce on anyone who might give a
simple example of LISP and therefore, in your opinion, simplify the
language or what it can do, I would have said AI instead of parser and
saved myself the trouble of being persecuted by a zealot.