And I fervently hope that does not change. Moving Emacs to the world of Gems/Bundler or Maven, where every package depends on two dozen half-assed libraries (each of which transitively use at least two dozen more), and where everything breaks all the time because someone decided to "upgrade" to the JSON parser in vogue this week, hardly strikes me as an improvement.
Personally, I think the problem in the Ruby world is the blazing pace at which folks are producing Ruby stuff.
But I agree with you, quicklisp is awesome.
I have done less with ruby lately, but as I recall the only way to survive was to use RVM or apparently now chruby to get everythin and compile it up.
I'll try that approach. Never really tried SBCL or Clozure CL.
> And i compile the source each time
You mean that you compile, for instance, Clisp? I tried to do it once, because FFI usage is dependent of a the flag --with-dynamic-ffi being set in the ./configure step [1][2]. I don't remember exactly why, but I got some difficulties in the build process, but I managed to do it.
This may be a little out of scope, but does anybody know about a common lisp implementation that is more FFI-friendly?
[1]: http://stackoverflow.com/questions/130636/how-to-compile-cli... [2]: http://stackoverflow.com/questions/3901698/is-there-a-way-to...
sbcl doesn't rely on the C compiler so you should have no problems building it on mac OS. Clozure CL was originally a CL specifically for the mac, so it definitely should work fine. SBCL seems to be the most popular open-source implementation, as it can generate extremely good code, often with just minimal type annotations.
By each time, I mean for updates to sbcl.
Don't install any other Common Lisp stuff SBCL doesn't depend on from the Debian repository though, except maybe ASDF. Get everything else through Quicklisp.
gem 'activesupport', '>= 2.3.5' # too loosely
I can understand cross-platform stability and one-button ease of use, but quite frankly, I've already got one-button ease of use (apt-get), and I long ago gave up on proprietary software that doesn't meet my needs (handling packages properly being one of them).
As for Emacs packages that haven't been packaged for my distro yet, the Emacs library itself is huge (hell, org-mode is now standard!), so if a package needs more than a repository checkout, add to load-path and require to get started, I'm going to have to question its quality.