Re: Better is better: improving productivity through programming
From: Michael Sullivan (michael_at_bcect.com)
Date: 04/05/04
- Next message: Will Hartung: "Re: Better is better: improving productivity through programming"
- Previous message: Russell Wallace: "Re: Macros still needed with shorter LAMBDA?"
- In reply to: Pascal Costanza: "Re: Better is better: improving productivity through programming"
- Next in thread: Jacek Generowicz: "[OT] STL, Stepanov [Was: Better is better: improving productivity through programming]"
- Reply: Jacek Generowicz: "[OT] STL, Stepanov [Was: Better is better: improving productivity through programming]"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 5 Apr 2004 17:20:40 -0400
Pascal Costanza <costanza@web.de> wrote:
> It's clear that the perceived (not necessarily real) lack of
> infrastructure (libraries, and so on) can and will probably be solved
> over time. Nothing (!) in Common Lisp prevents us from doing that.
There is nothing inherent in the language that prevents it, but the
sheer scale of the task of keeping up with all the various platforms and
interfaces and the way they change can mean that a lack of popularity
prevents it. Common Lisp is usable for almost any task at this point,
but having libraries that make the obvious things as easy as they are in
some other popular languages takes a *lot* of work. If the language
community is not of a certain size, there may not be a lucrative enough
market for commercial developers, or enough people willing to donate
their code to keep up with the changes in the computing world as
effectively as the most popular languages can.
I think it's debatable which side of that critical mass common lisp is
on right now. I think it's clear that if CL were much less popular --
it could be clearly on the "never able to keep up" side. Fortunately, I
get the sense that lisp's popularity has recently started growing again,
so I expect CL to get to the right side of that line if it isn't there
already.
> The
> lack of sufficient abstraction facilities in most other languages can
> only be solved by replacing them with yet other languages (including new
> versions thereof).
That is certainly true. One problem is that a huge number of money
problems can be hack solved without getting into the kind of complex
design where an HLL (in the lisp sense) can really shine. This leads to
a philosophy where interesting problems become considered "impossible"
because of the exponential programmer time complexity of dealing with
them in languages with insufficient abstraction facility.
The idea of using a language with better abstraction facility doesn't
occur to people who have never grokked such a language. Although that
said, before I ever learned lisp, I struggled with the lack of such
facility in common languages. Until I understood lisp and scheme enough
to realize that they did the very things I had for 15 years wished I
could do in other languages, I had just assumed that such facility was
"too hard to implement correctly".
What's too hard is doing it while maintaining total backwards
compability with your braindead ancestor language -- a la STL in C++,
which tries hard and is clearly influenced by lispy ideas, but stops
*far* short of being as usable as any reasonable lisp dialect.
Michael
- Next message: Will Hartung: "Re: Better is better: improving productivity through programming"
- Previous message: Russell Wallace: "Re: Macros still needed with shorter LAMBDA?"
- In reply to: Pascal Costanza: "Re: Better is better: improving productivity through programming"
- Next in thread: Jacek Generowicz: "[OT] STL, Stepanov [Was: Better is better: improving productivity through programming]"
- Reply: Jacek Generowicz: "[OT] STL, Stepanov [Was: Better is better: improving productivity through programming]"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
