> Previously, elisp package authors would try to make their code self-contained.

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.

quicklisp for lisp libraries is a smashing success.

Personally, I think the problem in the Ruby world is the blazing pace at which folks are producing Ruby stuff.

the problem is also dependencies specified as:

gem 'activesupport', '>= 2.3.5' # too loosely

In ubuntu, when using the packaged clisp and asdf (installable via apt-get), i'm unable to install quicklisp without some hacking around (it complains about the asdf version).

But I agree with you, quicklisp is awesome.

Ok, I never use the host os package manager for certain key things, including Lisp, Ruby. For Lisp, i get from the SBCL site or the proper site (SBCL, Clisp, Clozure CL) I am using. And i compile the source each time. (Obviously to bootstrap you gotta pull the binary the first time). After that, everything is a piece of cake.

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.

> For Lisp, i get from the SBCL site or the proper site (SBCL, Clisp, Clozure CL) I am using

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...

I heard that clang is now the default C compiler on OS X? clisp can't be built reliably with clang on x86_64 (clisp people on irc thought it was likely a bug in clang).

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.

I use sbcl--been a while since I used clisp.

By each time, I mean for updates to sbcl.

On Debian (and possibly Ubuntu) one can get the SBCL package from unstable (it doesn't depend on much) and go from there if installing from source is too much of a hassle.

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.

But we have at least one example of doing that right - CPAN.

How long did it take CPAN to get that way? And I still prefer my native OS to handle packages better than some random developers; that's one of the big reasons I chose it (Debian, for the record). Good developers aren't always good sysadmins. Add to that NIH syndrome, and you get things like Gems.

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.

And as a Debian user you know and use dh-make-perl when you need to, right? And it does the job with no troubles usually, right? And this is possible exactly because CPAN is the CPAN, not an half-baked bunch of packages that called "it like a CPAN for <language name>" too often.

Well, not every language culture is as tweaker as the Ruby world.

Ya, hardly anybody tweaks Emacs.

Emacs itself (as in the distribution) is extremely conservative. It's probably for the best it stay that way, precisely because it's so simple to hack on the software.

I don't think you need 'cl for dolist†. Unfortunately elisp doesn't have TCO, so what you would normally do with recursion in other lisps you have to do with loops in Emacs lisp.

† http://www.gnu.org/software/emacs/emacs-lisp-intro/html_node...

As a Lisp user I prefer loop constructs over recursion. It makes the iteration explicit.

Worth mentioning that two of these libraries are by the post's author.

make-hash-table is an abomination. Thanks for this.

(make-hash-table) is too difficult?

Enumerate the keys, please. Oh, no primitives? Well, you can just use maphash. But wait: maphash doesn't return values. So you need your k/v function to modify some state somewhere.

WAT

Fuck it, I'll just use an alist.

Enumerating keys makes (MAKE-HASH-TABLE) hard to use? What?

If you want to enumerate keys, write a function. In Common Lisp I write:

    (defun hash-table-keys (ht)
      (loop for k being each hash-key of ht collect k))

Done. That's Lisp. Need a function? Write it.

Cool, thanks. The problem here is in the elisp manual, then.