Re: problems with lisp

[Pascal Costanza <address@hidden>]

On Freitag, August 22, 2003, at 11:48  Uhr, Russ Ross wrote:

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

Wrt popularity, I think there are basically two options: either you can 
work with a popular language, or you can try to make your favorite 
language popular.

If it is really the case that the merits of popular languages are 
socially constructed, why don't we just reuse the popularity mechanisms 
that work for other languages? It seems to me that Paul Graham is just 
trying to do that.

For example, a good story to tell could be that, now that 
metaprogramming is gaining popularity, the meta language should have 
the same expressive power as the base language. Then we would be just 
another step closer to Lisp...

>> 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
> packaging?

I don't think so. Please check out what commercial vendors like 
Xanalys, Franz, Digitool, Corman, Scieneer, and so on, are actually 
offering. Don't draw your conclusions purely from open source 
implementations.

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

Sorry, misunderstanding, probably caused by sloppy wording on my side. 
I have meant something much simpler, like what CL actually has to 
offer, say, wrt array/vector functionality. (The "domain" in this case 
would be arrays. ;)

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

Clisp is a purely interpreted CL implementation. I guess your benchmark 
suffered from this - but this can only be determined from the actual 
code.

> I still think its a design problem if the natural idiom of a
> language produces inferior code.  It seems like a bait-n-switch
> otherwise.

Nope. Using a compiled Common Lisp probably helps.

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

I am sorry, I didn't get that.

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

...but the programming tips are actually important, even in this 
regard. Every language needs some getting used to, doesn't it? The 
problems you mention seem very superficial. Of course, superficial 
problems can actually harm the adoption of a language, but what else 
could we do than try to explain the details?


Pascal