[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: problems with lisp
On Fri, Aug 22, 2003 at 09:36:44PM +0200, Pascal Costanza wrote:
> You should consider restating your questions wrt Common Lisp in
> comp.lang.lisp - you will probably get some excellent advice there.
I'm not really seeking advice on Commmon Lisp. A few of the major
themes of this list seem to be:
1. what makes one language successful where another fails?
2. what directions are popular languages taking?
3. where should languages go in the future?
A common answer to the third that is often proposed is that
languages should be more lisp-like, and to the second people observe
that we are already moving in that direction. People quickly rally
to say that more people should be using lisp now, and then they
scratch their heads in confusion and wonder why lisp isn't more
popular. It is to this vocal part of the list that I am addressing
> AFAICT, the Common Lisp standard was not intended to be complete. You
> get a lot of add-ons in particular implementations, especially from the
> commercial vendors. Modularization concerns are typically covered by
> system construction facilities; networking, database access and the
> likes are also covered.
Okay, and that was fine ten or fifteen years ago. As Paul Graham
pointed out in one of his essays, a computer language these days
seems to encompass more than the language specification itself. It
also includes a (hopefully) high quality implementation, a useful
set of libraries, and a user community complete with code
repositories for more specialized libraries. Perhaps this is one of
the faults of lisp? It's a little too old fashioned in its
> The standard libraries might not be integrated as well as could be, but
> at least they were designed around tried and proven practices. In my
> experience, the libraries typically provide exactly the features you
> need for the domain at hand.
Which domain is that? Please don't say AI. If the features of lisp
are as great as people seem to think, shouldn't they be as great for
network applications, end-user GUI apps, enterprise software, etc?
I recognize that Common Lisp is an ageing standard, but that's a
problem, not an excuse.
> OCaml reportedly comes with an excellent compiler while clisp and gcl
> are not among the best CL implementations with regard to efficiency.
> You might want to try the exercise again with CMUCL or SBCL.
Perhaps my little experiment wasn't fair. clisp was the main
implementation I've used and it seems to have a good reputation
generally. I'll try again with those you mentioned if I get a
I still think its a design problem if the natural idiom of a
language produces inferior code. It seems like a bait-n-switch
> Another idea is to post the code to comp.lang.lisp and get some advice.
The contest is still open, so I'll refrain from posting code as that
wouldn't be very thoughtful to the contest organizers.
> P.S.: Is this still considered on-topic on this list? I don't want to
> annoy anyone...
It was intended to be on-topic. Again, I'm not really looking for
Common Lisp programming tips. I'm looking to see how Lisp fits into
the broader themes that this list covers. I think the language
concepts are great, but much of the rest of the story seems to be
missing. If #2 above helps us understand #1 and offers hints at #3,
then I think a discussion of how lisp fits in is entirely on-topic.