So I'm still trying to learn Lisp. It's a bit of a mixed experience.

Slime is quite good. I like the syntax prompting and I like having access to REPL commands via key-bindings in a Lisp source buffer in Emacs. So I can compile/evaluate expressions, functions, files easily.

The REPL is nothing special really. We had interactive interpreters in BASIC when we were children. And I regularly use the Python interactive interpreter for debugging, reminding myself of syntax, etc.

I was introduced to clbuild which manages installation and maintenance of Lisp libraries, taking the code directly from the projects' repositories. It's reminiscent of APT in Debian, but without any particular quality control. It tends to adopt a sort of brute force strategy for 'resolving' dependencies.

One thing that n00bs are supposed to find difficult which I've actually got on all right with is using functions as first class objects - passing them as arguments to other functions, storing them in lists, returning them form other functions, etc. I guess this is because I was already used to doing that kind of thing in Python anyway. Though in Common Lisp it's complicated by functions and other things (can you tell I don't really understand it?) occupying different namespaces and to access the function which a symbol represents you have to prepend the symbol with a nasty little bit of syntactic grubbiness: #'

I understand Lisp macros in principle but can't write them in practice. Again, more syntactic grubbiness. Lisp macros are expanded at compile-time into ordinary Lisp code. The macro definitions contain Lisp code which must be prepending with a ` to indicate that it will be returned as-is when the macro is expanded, or a , to indicate that it will be evaluated and the result returned when the macro is expanded. It gets grubbier, though. You can use ,@ to tell it to evaluate the following expression at expansion-time and splice its result into the returned code.

Also I don't understand keywords. They're prepending with some more syntactic grubbiness, a :. But I can never anticipate where libraries like CLIM and CLSQL will use keywords and where they'll use plain symbols.

Similarly, I don't like vectors/lists and hashes/a-lists (or p-lists, they're different things!) Far too many solutions to the same problem. I never know which I'm supposed to use. I don't like the fact that you use functions to managed them (e.g. access elements). In Python, the syntax for managing lists and dictionaries is very clean and predictable (not to mention well-documented).

It's downhill from here.

SBCL has the most dreadful debugger. Get this: it doesn't actually tell you what line of your source code it got stuck on!! Can you believe that? Even in C you get it tell you which line of your code you need to start hunting for the mistake from. I found someone's blog post about getting SBCL to give you line numbers but it somewhat misses the point. I'm a n00b, I have difficulty with even the simplest of functions. I really don't need to be dealing with non-trivial hacks just to get started in the language.

Another weird thing it does is that whenever you import library code, it seems to compile or something. In any case, it takes a long time to import a module and spews out lots of messages while it's doing it.

But there's something fundamentally more wrong with Lisp and it's community. There are Lisp libraries for just about everything. Which is great, except that in most cases there are several libraries which do the same thing. Some of those libraries are functionally incomplete. Pretty much all them have very little documentation. This is a real problem for people who are jobbing programmers who need to get stuff done, as well as for n00bs who want to progress beyond trivial number and string manipulation games and do some more interesting and pointful stuff like accessing their database or generating XML.

For example, I was trying out the CLSQL tutorial. And the first example I typed in contained a mistake. I found out what the problem was in a conversation form 2004. A particular bit of this library had been deprecated, but the tutorial hadn't been updated.

I think these are indicative of the problem with Lisp. It's by hackers for hackers. So libraries don't get completed because they're hacker projects that become uninteresting once they've been solved in principle. They're then not solved satisfactorily in practice because no one depends on them.

I still want to like Lisp but it's not making it easy so far. It's a very different experience to when I first started learning Python. Then, I found that all the things I normally did while writing programs were suddenly rendered simple. And it had a large, comprehensive and well documented standard library. I could write non-trivial Python applications (not just simple programs) without relying on any third party code and move them from one system to another without problems. And there was also a large selection of well written and often well documented libraries for doing all the things the standard library doesn't provide for.

Of course, come back in six month's time and I'll be a hardcore Lisp hacker flaming stupid n00bs like me who just don't get it.