> A package management system that you don't have to invoke lucifer to use would also help (leiningen for CL) What do you think are the biggest problems with A

> A package management system that you don't have to invoke lucifer to use would also help (leiningen for CL) What do you think are the biggest problems with ASDF? > A common threading model that makes sense would also be nice. Which memory model should this threading system guarantee? Which concurrency primitives? How is this going to be supported on all the different platforms the different CL implementations are available for? What do you think are the biggest problems with bordeaux-threads? > CLISP, SBCL, CMU-CL, GCL, ECL, ABCL, MKCL, MCL, Movitz, OpenMCL, CLiCC, Kyoto, CCL, Jatha, ThinLisp, UABCL, WCL, XCL CLiCC and ThinLisp are deployment tools and not full-blown implementations. Neither of them have been actively developed in the last decade (I was the last person to touch ThinLisp about 8(?) years ago). WCL is a shared library from the 90s. Kyoto, GCL, ECL, MKCL are forks/descendants of the same implementation (in that chronological order). Corman Common Lisp hasn't been developed in years. > good Lisp hackers seem more interested in writing yet another Common Lisp than extending the capabilities of existing ones. If you actually look, the two sets of people (Lisp library/application hackers and Lisp implementation maintainers) are pretty distinct. If someone wants to make another Common Lisp implementation, that doesn't take resources away from Common Lisp libraries, and it doesn't fracture the community (that's why standards are a good thing). It would be great to have better array libraries and package managers and thread libraries. Saying that having less Common Lisp implementations will make those things happen is a false dichotomy.