
Two years of Quicklisp - wglb
http://blog.quicklisp.org/2012/10/two-years-of-quicklisp.html
======
mark_l_watson
Zach has done a great job of seeing a need in the Common Lisp community and
writing a packaging system to meet that need.

I don't use Common Lisp as much as I used to but when I do I now use Quicklisp
for every project.

A further benefit of Quicklisp is being able to browse available packages and
quickly experiment with packages that may be useful. I think that Quicklisp
tightens up this exploratory cycle.

------
leephillips
I suggest placing a link somewhere that will lead me to something telling me
what Quicklisp is.

~~~
prodigal_erik
From a look at <http://www.quicklisp.org/beta/>, it looks like another single-
language tool for smuggling code onto a box while failing to set up any
interdependencies with the system's package manager. I don't like being so
harsh, but "every language has its own packages and none of them interop at
all" is a growing antipattern that eventually leads to horrible messes.

~~~
sgrove
So write a blog post elsewhere about it. It's one I'd absolutely be interested
in reading.

But posting this 'harsh' comment here is useless and detracts from useful
conversation.

~~~
prodigal_erik
Seen complaints about startups which are obviously saving passwords in
plaintext? Imagine how much worse it would be if all the "why you shouldn't it
that way" criticism was consigned to obscure blogs rather than here. I regard
this as that kind of problem--huge long-term drawbacks that people don't
proactively go looking into and don't immediately deter implementing the idea.

~~~
bobba
If you want something done then you need to start on it yourself. Disregarding
what QuickLisp has accomplished because you have to deal with more than one
package management system is trollish. You'll probably want to start by
designing a plugin framework that can support multiple versions of any given
language. Also need to be able to bundle dependencies per application, on any
operating system, so that you don't pollute the global package space for any
one given application under developement. kthx

------
barakm
This seems incredibly useful; for someone who wants to try it out, which is a
good, open-source, cross-platform CL to try it on? The example uses SBCL, but
I know none of the tradeoffs.

~~~
enduser
SBCL is perhaps the fastest open-source implementation of Common Lisp. It has
incredible developers and a rich set of implementation-specific functionality.
SBCL's "home platform" is Linux, but it runs on Linux, *BSD, Mac, and Windows
(32-bit only for Windows at present). SBCL's native code compiler rivals C/C++
for speed when properly hinted. SBCL also has the highest-quality integration
with emacs (via SLIME) and Vim (via slimv). The developers seem to expect that
you will use SBCL with an editor, so the command-line REPL doesn't even have
readline support. ITA Software uses SBCL to run all or most of QPX, the search
engine behind sites like Orbitz and Expedia. SBCL does its own memory
management and likes a large heap. Standalone executable size is large (20+MB)
because it includes the compiler. SBCL is derived from CMUCL and thus has a
32-years-mature lineage and is very stable and performs very well. SBCL has
excellent threading , Unicode, and 64-bit support.

CLISP is another implementation that is interpteted (i.e. not native-compiled
like SBCL i.e. slower in most cases). It has a somewhat nicer REPL and
debugger out of the box, and super-fast bignum support. I believe CLISP is
what pg used to create Viaweb.

There is also Clozure Common Lisp (predating and not to be confused with
Clojure). CCL is well integrated with Cocoa on the OS X platform and seems to
be moving in the direction of ARM suport (iOS support in the future?). I have
the impression that CCL may be more popular with OS X users, but I have yet to
find reason to use it over SBCL on Linux.

ECL (Embedded Common Lisp) is an implementation that translates to C and uses
gcc for compilation. ECL builds the tiniest executables (a couple hundred K or
less) and is perhaps well-suited both as an extension language and for
embedded platforms. ECL does not seem to support all of the libraries I've
tried with it, but it supports enough of Common Lisp to be a viable platform
for those who require its strengths.

