Troels Henriksen writes in his blog about
library use in the Common Lisp community. It's really funny that he cites UCW as a good example of library usage, whereas I have encountered
several problems exactly because of UCWs library dependencies. Another example would be
CL-SQL .
Now, in Troels comment section, some unknown poster suggested looking at the integrated XEmacs packaging system. I'm not convinced that this solves the real problem, though, as it doesn't deal with version issues at all besides providing a feature to update to a newer version. But incompatibilites between versions is the major obstacle identified (correctly) by Troels. Revisit UCW: UCW includes (or at least it did when I last checked some months ago)
several forked-off versions of some libraries it depends on.
I'm also not convinced that fixing or enhancing the package tools is the right way to go. I think that the major issue is that many CL libraries are far from the stableness that e.g.
CL-PPCRE provides. Otherwise, e.g. UCW wouldn't need to provide a box set of it's own versions of libraries, and believe me, I'm very grateful for that box set. I think that the only real solution is working on the libraries.
I also believe there is another reason for many programmers not to rely on external libraries: The fear of bloat. CL traditionally has a very bad reputation with regard to execution speed and memory usage. Now, right after loading UCW in a fresh SBCL, I see the following in top:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
11861 schauer 15 0 894m 79m 15m S 0.0 7.8 0:13.22 sbcl
This is a lot of memory which might be a reason why many programmers might feel it's easier to start developing their own application-specific solution.
Another reason might be that Lisp programmers often try to accomplish a solution in terms of the problem domain and this might sometimes conflict with the approaches taken in the libraries. To some degree, this is the Not-Invented-Here issue in cloak (eek, I don't like it this way, I'll go my way instead), but it also touches a lot on issues of style which can't be argued about.
