Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > OFF-TOPIC:: Why Lisp is not my favorite programming language

Reply
Thread Tools

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

 
 
goose
Guest
Posts: n/a
 
      03-05-2004
http://www.velocityreviews.com/forums/(E-Mail Removed) (Mike Nishizawa) wrote in message news:<(E-Mail Removed). com>...

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,
 
Reply With Quote
 
 
 
 
Ray Dillinger
Guest
Posts: n/a
 
      03-05-2004
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
 
Reply With Quote
 
 
 
 
Yuri Schaeffer
Guest
Posts: n/a
 
      03-05-2004
I goofed!

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
 
Reply With Quote
 
Michael Borgwardt
Guest
Posts: n/a
 
      03-05-2004
goose wrote:

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

 
Reply With Quote
 
Aahz
Guest
Posts: n/a
 
      03-05-2004
[c.l.py added back in]

In article <(E-Mail Removed)>, Ray Dillinger <(E-Mail Removed)> wrote:
>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.


OTOH, using a braindead netnews client that reposts the same content
tends to destroy one's credibility.
--
Aahz ((E-Mail Removed)) <*> http://www.pythoncraft.com/

"Do not taunt happy fun for loops. Do not change lists you are looping over."
--Remco Gerlich, comp.lang.python
 
Reply With Quote
 
Mike Nishizawa
Guest
Posts: n/a
 
      04-06-2004
(E-Mail Removed) (Minti) wrote in message news:<(E-Mail Removed). com>...
> (E-Mail Removed) (Mike Nishizawa) wrote in message news:<(E-Mail Removed). 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.
 
Reply With Quote
 
Stephen Horne
Guest
Posts: n/a
 
      04-07-2004
On 6 Apr 2004 13:58:45 -0700, (E-Mail Removed) (Mike Nishizawa)
wrote:

>(E-Mail Removed) (Minti) wrote in message news:<(E-Mail Removed). 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
 
Reply With Quote
 
Russell Lear
Guest
Posts: n/a
 
      04-07-2004
Stephen Horne wrote:

> On 6 Apr 2004 13:58:45 -0700, (E-Mail Removed) (Mike Nishizawa)
> wrote:
>
>>(E-Mail Removed) (Minti) wrote in message
>>news:<(E-Mail Removed) 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.

 
Reply With Quote
 
Piet van Oostrum
Guest
Posts: n/a
 
      04-07-2004
>>>>> Stephen Horne <(E-Mail Removed)> (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 <(E-Mail Removed)>
URL: http://www.cs.uu.nl/~piet [PGP]
Private email: (E-Mail Removed)
 
Reply With Quote
 
Michele Simionato
Guest
Posts: n/a
 
      04-07-2004
Stephen Horne <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>. ..

> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
pat-match.lisp or extend-match.lisp in Python? ekzept Python 0 08-10-2007 06:08 PM
findcontrol("PlaceHolderPrice") why why why why why why why why why why why Mr. SweatyFinger ASP .Net 2 12-02-2006 03:46 PM
OFF-TOPIC:: Why Lisp is not my favorite programming language nobody Java 28 04-15-2004 02:18 PM
OFF-TOPIC:: Why Lisp is not my favorite programming language nobody C Programming 26 04-15-2004 02:18 PM
OFF-TOPIC:: Why Lisp is not my favorite programming language nobody C++ 26 04-15-2004 02:18 PM



Advertisments