>>>>> "Janos" == Janos Blazi <······@netsurf.de> writes:
>> Can you say libraries?
Janos> What do you mean by that? Are there standard libraries for CL?
Janos> (Actually one of the shortcomings of CL in my eyes is the lack
Janos> of such libraries (like C has for example and even Python). I
Janos> think the the c.l.l community could create such libraries in 6
Janos> months... sigh.
Some of the reason for that is that CL needs much less libraries
because it contains so much more than for instance C or Scheme.
Compare the weight of CLtL with R?RS for reference.
---------------------------+--------------------------------------------------
Christian Lynbech | Ericsson Telebit A/S
Fax: +45 8628 8186 | Fabrikvej 11, DK-8260 Viby J
Phone: +45 8738 2228 | email: ···@tbit.dk --- URL: http://www.tbit.dk
---------------------------+--------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)
Christian Lynbech <···@tbit.dk> writes:
> Janos> What do you mean by that? Are there standard libraries for CL?
> Janos> (Actually one of the shortcomings of CL in my eyes is the lack
> Janos> of such libraries (like C has for example and even Python). I
> Janos> think the the c.l.l community could create such libraries in 6
> Janos> months... sigh.
>
> Some of the reason for that is that CL needs much less libraries
> because it contains so much more than for instance C or Scheme.
>
> Compare the weight of CLtL with R?RS for reference.
There is also less willingness to produce the sort of throw-away
libraries that are common in other languages, for areas where the
issues involved in providing a decent, _stable_ interface have not
been understood yet by the implementors.
Whether this is good (i.e. mostly only high-quality, stable libraries
available for CL), or bad (cf. the worse is better argument by
Gabriel) is IMHO not clear. I certainly can see the reasoning that CL
could use some dirty but useable libraries for quick&dirty things
(like much WWW work) which can then evolve into real CL libraries.
Without this kind of unhindered public experimentation, starvation
might occur.
OTOH I see the problems which are caused by the Perl phenomenon (a
host of small, often unstable, quickly obsoleted libraries), too, and
I'm happy to produce software whose life-time will exceed that of the
package de-jour which will be obsolete by next year.
To put it another way: It's nice to be able to quickly produce
something useful with little effort using libraries. It's even nicer
to produce something very useful with reduced effort using libraries.
It's much nicer still if this work will be maintainable with reduced
(instead of increased) effort because of stably co-evolving libraries.
Anyway, it seems that some movement has come into the open CL library
market, so let's see how we might try to get the best of both worlds.
Turning to Alan Perlis' quip, we might say that Common Lisp programmers
know the cost of many things, as well as their values. ;)
Regs, Pierre.
--
Pierre Mai <····@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]