OFF-TOPIC:: Why Lisp is not my favorite programming language

[nobody]

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 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]

nobody wrote:

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]

In comp.lang.c nobody <no****************@yahoo.com> wrote:
^^^^^^^^^^^

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.
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.

--
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]

nobody wrote:

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]

no****************@yahoo.com (nobody) writes:

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]

nobody wrote:

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]

I don't know what this post has to do with comp.lang.c, but whatever.

This was pretty funny nonetheless.

As for me, I would say practically the same things about Java. :-p

[Kaz Kylheku]

no****************@yahoo.com (nobody) wrote in message news:<16**************************@posting.google. com>...

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]

nobody wrote:

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 "no****************@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]

Something that calls itself nobody wrote:

[snip]

This is an obvious troll. Please ignore it.

[Bootstrap Bill]

"Claudio Puviani" <pu*****@hotmail.com> wrote in message
news:lo**********************@news4.srv.hcvlny.cv. net...

"Bootstrap Bill" <wr*******@yahoo.com> wrote

"Dale King" <kingd[at]tmicha[dot]net> wrote in message
news:40******@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?

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

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.

My 13 year old niece wants to learn programming. What's the best
introductory language for her?

[Josiah Carlson]

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.

My 13 year old niece wants to learn programming. What's the best
introductory language for her?

Really, depending on what you want to teach her (programming is fun vs.
programming can be a pain in the ass), that should define which language
you should send her off to learn.

1. Teach her Scheme for a couple months to get her mind around the idea
of recursion (very beneficial to all new programmers).
2. Spend a couple months teaching her C so that she gets the feeling for
a statically typed system and dealing with pointers.
3. Spend a month teaching her object orientation with C++.
4. If you feel up for it (I wouldn't be), spend a couple weeks on Java.
5. Once she's feeling good with the ideas behind programming, spend an
afternoon teaching her Python, and give her a week to convert everything
she ever did to Python.
6. Reap the rewards of a Python convert.

- Josiah

[Josiah Carlson]

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.

My 13 year old niece wants to learn programming. What's the best
introductory language for her?

Really, depending on what you want to teach her (programming is fun vs.
programming can be a pain in the ass), that should define which language
you should send her off to learn.

1. Teach her Scheme for a couple months to get her mind around the idea
of recursion (very beneficial to all new programmers).
2. Spend a couple months teaching her C so that she gets the feeling for
a statically typed system and dealing with pointers.
3. Spend a month teaching her object orientation with C++.
4. If you feel up for it (I wouldn't be), spend a couple weeks on Java.
5. Once she's feeling good with the ideas behind programming, spend an
afternoon teaching her Python, and give her a week to convert everything
she ever did to Python.
6. Reap the rewards of a Python convert.

- Josiah

[Peter Hickman]

Josiah Carlson wrote:

3. Spend a month teaching her object orientation with C++.

Perhaps Ruby for the OO stuff if you are familier with it. Less gotcha's
than C++. All depends on the sort of person she is.

A wide range of programming languages is always a good idea. How about
Prolog just for the hell of it?

[Ville Vainio]

>>>>> "Peter" == Peter Hickman <pe***@semantico.com> writes:

Peter> Josiah Carlson wrote:

3. Spend a month teaching her object orientation with C++.

Peter> Perhaps Ruby for the OO stuff if you are familier with it. Less
Peter> gotcha's than C++. All depends on the sort of person she is.

You missed Josiah's point (at least as I understood it) - the idea was
to show how painful programming can be, and then experience the
revelation of switching to Python. It's a standard practice in some
religious circles, where people are guided to wallow in remorse of
original sins and other unpleasant stuff, and then feel the relief of
divine forgiveness.

As a side note, Ruby has no OO advantages over Python. This has been
discussed in this newsgroup extensively.

--
Ville Vainio http://tinyurl.com/2prnb

[Peter Hickman]

Ville Vainio wrote:

You missed Josiah's point (at least as I understood it) - the idea was
to show how painful programming can be, and then experience the
revelation of switching to Python. It's a standard practice in some
religious circles, where people are guided to wallow in remorse of
original sins and other unpleasant stuff, and then feel the relief of
divine forgiveness.
Then you need to throw in some Intel assembly!
As a side note, Ruby has no OO advantages over Python. This has been
discussed in this newsgroup extensively.

Never said it had but I was aiming for a wide range of languages to show
that TIMTOWTDI. A good programmer should be familiar with a wide range
of languages and techniques. Prolog shows a style of programming,
declarative, that is not easy to experience in Python (or Perl or Ruby
or C but perhaps in Icon), a more procedural type of language.

If all you want her to be is a Python zealot then go ahead, but you
would be doing her a greater service by allowing her to become a good
programmer.

I take it her name isn't Josiah Jr?

[Ville Vainio]

>>>>> "Peter" == Peter Hickman <pe***@semantico.com> writes:

Peter> If all you want her to be is a Python zealot then go ahead,
Peter> but you would be doing her a greater service by allowing
Peter> her to become a good programmer.

It's just that I don't think Python and Ruby are different enough as
languages to really provide much perspective from pedagogical
viewpoint.

--
Ville Vainio http://tinyurl.com/2prnb

[Josiah Carlson]

> I take it her name isn't Josiah Jr?

*laugh* god I hope not. I would have had to father her by the time I
was 10.

That would be a seriously funny surprise to my wife and parents, "um
guys, I just found out that back when I was 10, I gave a girl my cooties."

In all seriousness though, I think that kids should learn some Assembly,
if only because it gets to be fun to reorganize cycle by cycle
execution. Maybe not at 13, but at least 2nd year of undergraduate CS
education.

- Josiah

[Russell Wallace]

On Wed, 10 Mar 2004 04:03:09 GMT, "Bootstrap Bill"
<wr*******@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]

Program a game - it's fun for a 13year old. And games are made with GLBasic
from GLBasic.com.
qed.

Gernot Frisch.
"Russell Wallace" <wa**************@eircom.net> schrieb im Newsbeitrag
news:40***************@news.eircom.net...

On Wed, 10 Mar 2004 04:03:09 GMT, "Bootstrap Bill"
<wr*******@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 afforda system with a floppy drive, let alone a hard drive.. I spent nearly all myfree 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

[Minti]

ni****@netzero.net (Mike Nishizawa) wrote in message news:<d7**************************@posting.google. com>...

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.

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"

[Roger Binns]

> 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.

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]

According to Minti <mi************@yahoo.com>:

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]

mi************@yahoo.com (Minti) wrote in message news:<e8**************************@posting.google. com>...

ni****@netzero.net (Mike Nishizawa) wrote in message news:<d7**************************@posting.google. com>...

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.

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

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.

[Stephen Horne]

On 6 Apr 2004 13:58:45 -0700, ni****@netzero.net (Mike Nishizawa)
wrote:

mi************@yahoo.com (Minti) wrote in message news:<e8**************************@posting.google. com>...

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.

It wouldn't surprise me. LISP is normally interpreted - maybe always,
though I'm not certain of that. The interpreter would be written in C.
And, depending on the implementation, the built-in list operations may
well be much more basic than those in Python, for instance, meaning
that more of the relatively sophisticated operations will be handled
using interpreted library code.

Python itself is at least 10 times slower than C for many things
(though the library often provides efficient algorithms that are
actually faster than anything you'd write for yourself even in C).

An implementation that has more of the standard operations built in,
or which used just-in-time compilation etc, may well run much faster.
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.
It is always possible to beat any interpreted language for speed using
C if you are willing to put in the time and effort. 90% or more of
interpreters were written in C themselves, and by writing directly in
C you are avoiding the need for any interpreting at run-time.
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.

Parsing isn't that heavy in list processing. Neither is handling a
large document.

In parsing, you are mostly dealing with one symbol at a time. The way
you access that symbol, whether you read it directly from a file or
input stream at need or keep it in a memory buffer, is the least
significant thing going on in the parser. Though the work done by most
practical parsers at run-time (rather than when the parser tables are
generated from the grammar) is not that complex. In most cases in
parsing, the language is pretty much immaterial. Though the
table-generating for, for instance, an LR-style parser (basically what
a tool like yacc does) needs to do a lot of set operations on
potentially quite large sets, and some fairly time consuming searches
and closures. Basically, it's something I wouldn't want to do in Lisp
purely for speed reasons. I have done it in Python, and the result
wasn't exactly practical - though it probably could have been with
more work and some C extension optimisations.

With large documents, while you can see the document as being a
(potentially huge) list of characters or words, you wouldn't want to
use a simple flat list data structure, again for performance reasons.
You wouldn't use a linked list because it would take too much time to
iterate through, not to mention the potentially very large storage
overhead - two pointers for a doubly-linked list takes 8 bytes, more
than the average word, and that's not even considering mallocs
rounding-up-to-a-multiple-of-x-bytes overhead. You wouldn't use a
simple resizable array because of the time wasted on insertions and
deletions, shifting the tail end backward and forward in memory.

I've never done this for a mutable document (I have for an immutable
document, but you can get away with a lot in that case) but I figure
that I'd create a kind of database table of 'chunks', along with a few
indexes into that table (using either tree or hash based methods). And
style and other non-text information would probably mostly be
separated out into other tables, with their own indexes. ie I would
learn a trick or two from the relational database guys, who have been
handling large sets of data reliably and efficiently for a long time.

Actually, this in-memory relational database thing is quite a useful
technique. In particular, it helps to reinforce the idea of keeping
your main data in an easily accessible place, and not hidden deeply in
the private internals of various of classes - so when you need to do
something you didn't anticipate before, the data you need to access is
easily available with maybe just an extra method or two on your
datastore object. Data hiding should only be done with care IMO.

Anyway, again this isn't a very big issue in terms of language
selection. Python might be a pretty good choice, though, simply
because there is both a convenient data-table type (list of tuples)
and a convenient index type (dictionary) built-in and ready to go.
Though I suspect a C extension might be needed to get good performance
for a few operations with very large documents on slow machines.

C++ is also in the running with the STL containers - harder to use, a
little more flexible, hard to say on speed. Python may actually be
faster as hashing is normally faster than red-black trees for handling
indexes, but then hashes don't support efficient in-order iteration so
it depends on how the data is accessed as much as anything.
--
Steve Horne

steve at ninereeds dot fsnet dot co dot uk

[Russell Lear]

Stephen Horne wrote:

On 6 Apr 2004 13:58:45 -0700, ni****@netzero.net (Mike Nishizawa)
wrote:

mi************@yahoo.com (Minti) wrote in message
news:<e8**************************@posting.googl e.com>...

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.

It wouldn't surprise me. LISP is normally interpreted - maybe always,
though I'm not certain of that. The interpreter would be written in C.
And, depending on the implementation, the built-in list operations may
well be much more basic than those in Python, for instance, meaning
that more of the relatively sophisticated operations will be handled
using interpreted library code.

I'm not sure what version of LISP you're talking about here, but modern LISP
implementations are actually quite efficient. I've run a web server
implemented in Scheme (a Lisp varient) with the equivalent of JSP pages -
and I believe performance would compare favorably with the equivalent Java
or Python. Not that I'd take on IIS or Apache, but they suffice for many
situations. (I know that FranzLisp offers an Enterprise version. But
there's too many digits in the price tag for me to bring one home.)

I've also written some graphics programs and they performed as well as Java.
(again, I wouldn't try to re-implement a 3D video game in it, but it did ok
for menus, card games or turtle graphics).

Certainly LISP started out as a list processing language, but it's grown up
in the last 40 years. The Lisp programmer has access to hashtables, trees
and the usual OO tools of inheritance, polymorphism, macros, etc. And, if
specialized or high-performance libraries are needed, most Lisp
implementations provide for extensions similar in concept to Python's.

I'm not pushing a Lisp agenda here - I actually prefer Python - but I don't
think people should dismiss Lisp as being a language suitable only (or
mainly) for list processing.

Russell.

[Piet van Oostrum]

>>>>> Stephen Horne <st***@ninereeds.fsnet.co.uk> (SH) wrote:

SH> It wouldn't surprise me. LISP is normally interpreted - maybe always,
SH> though I'm not certain of that.

This is one of the misconceptions about Lisp. Many Lisp systems do have an
interpreter on board, for interactive use but also most do have
compilation. There are some that don't even have an interpreter, nand even
for interactive use compile things without the user being aware of it. The
speed of compiled Lisp programs can approximate the speed of equivalent C
programs.
--
Piet van Oostrum <pi**@cs.uu.nl>
URL: http://www.cs.uu.nl/~piet [PGP]
Private email: P.***********@hccnet.nl

[Michele Simionato]

Stephen Horne <st***@ninereeds.fsnet.co.uk> wrote in message news:<6i********************************@4ax.com>. ..

LISP is normally interpreted - maybe always, <snip>

I think you will be crucified for that affirmation. Anyway, here is an
interesting thread talking about Lisp optimizations:

http://groups.google.it/groups?hl=it....lang.python.*

The gist is "Lisp can be faster than C/C++".
Michele Simionato

[Jacek Generowicz]

ni****@netzero.net (Mike Nishizawa) writes:

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.

[Jacek Generowicz]

Stephen Horne <st***@ninereeds.fsnet.co.uk> writes:

It wouldn't surprise me. LISP is normally interpreted - maybe
always,

Hmm.

Lemme see, here are some popular Common Lisp systems:

Clisp: http://clisp.cons.org/ - includes an interpreter and bytecode
compiler.

CMUCL: http://www.cons.org/cmucl/ - includes an interpreter bytecode
complier and native compiler.

SBCL: http://sbcl.sourceforge.net/ - has no interpreter; interactive REPL[1]
complies everything to native immediately.

OpenMCL: http://openmcl.clozure.com/ - has no interpreter; interactive
REPL compiles everything to native.

Allegro: http://www.franz.com/products/ - includes an interpreter and
native compiler.

LispWorks: http://www.lispworks.com/ - includes an interpreter and
native compiler.

MCL: http://www.digitool.com/ - has no interpreter; interactive REPL compiles
everything to native as soon as it is entered.

Corman: http://www.cormanlisp.com/ - includes a native compiler

[1] REPL - Read Eval Print Loop. Essentially what Python's interactive
shell is.
Now just what do you mean when you say "LISP is normally interpreted" ?

(Note: only one of the 8 systems mentioned above does not have a
native compilation facility, while three of them give you no way of
avoiding compiling to native.)

[Jacek Generowicz]

mi***************@poste.it (Michele Simionato) writes:

Stephen Horne <st***@ninereeds.fsnet.co.uk> wrote in message news:<6i********************************@4ax.com>. ..

LISP is normally interpreted - maybe always, <snip>
I think you will be crucified for that affirmation.

Yes, maybe crucifiction is a more appropriate reaction :-)
Anyway, here is an interesting thread talking about Lisp
optimizations:

http://groups.google.it/groups?hl=it....lang.python.*

Eh, methinks you posted the wrong link.

Did you mean to point to this thread containing this post:

http://www.google.ch/groups?as_umsgi...%40ccs.neu.edu

?

[Summary: Troll comes to c.l.l claiming that Lisp is slow. Challenges
Lispniks to try to beat C++ on speed on a program that was designed to
test speed of C++ compilers. Lispniks beat C++ for speed in both
Common Lisp and Scheme.]

[Matthias]

Stephen Horne <st***@ninereeds.fsnet.co.uk> writes:

On 6 Apr 2004 13:58:45 -0700, ni****@netzero.net (Mike Nishizawa)
wrote:

mi************@yahoo.com (Minti) wrote in message news:<e8**************************@posting.google. com>...

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.

It wouldn't surprise me. LISP is normally interpreted - maybe always,
though I'm not certain of that. The interpreter would be written in C.
And, depending on the implementation, the built-in list operations may
well be much more basic than those in Python, for instance, meaning
that more of the relatively sophisticated operations will be handled
using interpreted library code.

Sounds reasonable, but is almost completely false:

1.) Lisp is normally compiled. (Almost every Common Lisp
implementation compiles to native code, as do many Scheme
implementations.)

2.) The built-in list operations are at least as sophisticated as Pythons.
(Common Lisp's are more sophisticated.)

3.) Lisp is normally much faster than Python and comes "close" to C
(depends on how much you care to optimize your Lisp code). See
http://www.norvig.com/python-lisp.html (the colorful table at the
bottom of the page) for some data.

[Michele Simionato]

Jacek Generowicz <ja**************@cern.ch> wrote in message news:<ty*************@pcepsft001.cern.ch>...>

Eh, methinks you posted the wrong link.

Did you mean to point to this thread containing this post:

http://www.google.ch/groups?as_umsgi...%40ccs.neu.edu

?

[Summary: Troll comes to c.l.l claiming that Lisp is slow. Challenges
Lispniks to try to beat C++ on speed on a program that was designed to
test speed of C++ compilers. Lispniks beat C++ for speed in both
Common Lisp and Scheme.]

Ick! I had the wrong link in the clipboard! I am using a new machine at
work and sometimes the clipboard surprises me. Anyway yes, I was
referring to the thread you mention. Sorry about the mistake.

Michele Simionato

[Stephen Horne]

On 07 Apr 2004 13:43:26 +0200, Jacek Generowicz
<ja**************@cern.ch> wrote:

Did you mean to point to this thread containing this post:

http://www.google.ch/groups?as_umsgi...%40ccs.neu.edu

?

[Summary: Troll comes to c.l.l claiming that Lisp is slow. Challenges
Lispniks to try to beat C++ on speed on a program that was designed to
test speed of C++ compilers. Lispniks beat C++ for speed in both
Common Lisp and Scheme.]

OK, I'm seriously out of date and possibly just plain wrong. It should
be clear that I didn't have any particular implementation in mind, and
neither did Mike who I was replying to. The only implementation of
Lisp I ever used, a very long time ago, had given every appearance of
being a pretty simple interpreter and the only time I ever saw a Lisp
implementation as source code it was an interpreter, and given the
kind of metaprogramming possible in Lisp (which for compilation to
work, must imply just-in-time compilation at run time) I just never
questioned the 'Lisp is interpreted' assumption.

Big mistake. Thanks for letting me know.

Though the 30* slower that C claim must be one of three things...

1. An interpreter, presumably with relatively simple builtins and
most more sophisticated stuff handled through libraries.

2. The worst compiler code generation in history.

3. A complete fabrication.

In my defence, I did say...

: An implementation that has more of the standard operations built in,
: or which used just-in-time compilation etc, may well run much faster.

In other words, I was making the point right from the start that
performance depends on the implementation and these figures may be
from a bad one. Though obviously I wasn't aware how exceptionally bad.
--
Steve Horne

steve at ninereeds dot fsnet dot co dot uk

[Stephen Horne]

On 07 Apr 2004 13:32:49 +0200, Jacek Generowicz
<ja**************@cern.ch> wrote:

Now just what do you mean when you say "LISP is normally interpreted" ?

That would be "I'm at least twenty years out of date, and stupid as
well for not checking my facts before posting".

Sorry.
--
Steve Horne

steve at ninereeds dot fsnet dot co dot uk