> You have lot of good libraries in clojure, as well as clojurescript for the front end with nice js interop.

I've been writing Clojure for about a month now, and I love it.

My background is mostly in Python, and I picked up Ruby about a month before Clojure. My rampup in Ruby was really about a week, given that much of it is so similar to Python - it was mostly about learning conventions and what the community considers to be "idiomatic Ruby".

Clojure was much more difficult to learn, and much more fulfilling/enjoyable. It's definitely changed the way I think about my code in all languages and that's a good thing. One thing I will say though is that the majority of the time I've spent struggling with Clojure has actually been struggling with Java.

For example, I wrote a collection of forms that decrypt and validate an auth token sent by a third-party legacy application. This required using java.crypto, which was a nightmare. I was porting code from Ruby, which was using OpenSSL. At one point I had references for Clojure, Java, Ruby, OpenSSL, and C all open at once, trying to figure out what was going on. In the end that particular problem was because Ruby's OpenSSL wrapper magically use an IV of eight null bytes if you don't supply one while java.crypto didn't use one at all - but it was one of the more difficult issues I've had to debug in recent memory.

I guess what I'm trying to say is that I would absolutely recommend Clojure as a first Lisp to learn, but I would also suggest that the person doing so either already have some experience in Java or have a way to reach out to someone who does.

I'm planning on picking up CL at some point soon as well, but from what I've experienced and gleaned from the experience of others Clojure is probably the better choice is your area of interest is mostly the web, because of the dev community and access to Java libraries.

Clojure is pretty drastically different from Lisp in most ways. If you wrap your head around macros in Clojure that will mostly carry over to CL, but just about everything else will be a learning experience. They're both very cool languages, but much more different from each other than for example Python and Ruby are. If you're interested in Lisp, learning Clojure first is sort of like learning Spanish because you're interested in French.

> Clojure is pretty drastically different from Lisp in most ways.

I remember tinkering with Scheme when I was much less experienced, and getting hung up on the constant recursion and singly-linked nature of the iterables. I'll get back to that, but I strongly suspect that Clojure will remain more practical for the type of work I do (back-end web, mostly).

> If you wrap your head around macros in Clojure that will mostly carry over to CL

I've not tackled writing them yet, but I've read a ton of the language internals and other people's code and I'm getting to the point where I can anticipate where they've used macros and why. I've also begun reading - slowly - Let Over Lambda, which has kinda blown my mind. My colleagues with more Clojure experience strongly advise me to treat macros as black magic that should rarely be used, but my opinion is slowly but surely going the other way. Macros seem like most of the point of using a homoiconic langauge, and to reserve them for edge cases seems unduly conservative. We'll see if that opinion changes as I learn more and begin to use them in my own work.

> If you're interested in Lisp, learning Clojure first is sort of like learning Spanish because you're interested in French.

I'm honestly not sure what I'm interested in learning right now. I feel like I fully grok Python. Though of course there are things I can't sit down right now and write without looking at a reference, I know what tools to use when and why they're appropriate. Having not acquired a compsci degree, I'm basically looking into the more esoteric languages and design patterns at this point, trying to find concepts that expand my abilities and knowledge. FP was one of those things, the concept of homoiconicity was one, and macros seem to be another.

Haskell looks interesting to me as well, but I'm cautious of the passion of their community. My impression is that they believe they are the "one true functional language", and with things like Lisp having been around for much longer in that role that seems a little too "flavor of the month" for me.

> I remember tinkering with Scheme when I was much less experienced, and getting hung up on the constant recursion and singly-linked nature of the iterables.

No one writes code like that in Common Lisp. Both Scheme and CL have more than singly-linked lists, as well.

> I've also begun reading - slowly - Let Over Lambda, which has kinda blown my mind.

I haven't read that one but I've heard good things. I can personally vouch that Paul Graham's On Lisp is excellent, as a book on macros, Lisp, or just in general.

> My colleagues with more Clojure experience strongly advise me to treat macros as black magic that should rarely be used, but my opinion is slowly but surely going the other way. Macros seem like most of the point of using a homoiconic langauge, and to reserve them for edge cases seems unduly conservative. We'll see if that opinion changes as I learn more and begin to use them in my own work.

If a function will do, use a function, but macros serve a different purpose. Over time you build up an intuition for which one you need in which situations.

> I'm basically looking into the more esoteric languages and design patterns at this point, trying to find concepts that expand my abilities and knowledge.

That's a very good strategy :)

> I'm basically looking into the more esoteric languages and design patterns at this point, trying to find concepts that expand my abilities and knowledge

It looks like I'm a bit further on this particular road, so let me give some suggestions:

1. Take a look at array-based programming languages. I used J (google "J lang" or got to jsoftware.com). It's incredible how you can have a single, two characters long symbol encode concepts such as recursiveness and have that symbol be easily composable with any other function in the language. Learning J or APL or K will change the way you think about tables, probably influencing both your NumPy code and SQL code.

2. Try some concatenative languages. Forth and Factor are fine examples in this category. Forth is a very low-level, completely untyped language with built-in interactive mode; it's mostly built in itself and bootstraped with a bit of assembler. Factor is a modern language with rich data types and batteries-included style standard library. Both use stack for passing arguments and both are interactive, but that's all they have in common, so learning both is not a waste of time.

3. Learn a pure object-oriented language, like Smalltalk (I think Pharo is the most popular implementation right now). It's not at all Java-like experience, having only objects at your disposal is not that bad if you can make the objects behave just the way you want them to: even things like the stack are objects and can be inspected and manipulated like all other objects. There's also Io to look out for: it's not as impressive as a full Smalltalk environment, but it's even simpler semantically and allows easy syntactic extensions.

4. Learn a logic programming language. It's great for quickly solving silly puzzles. It's not bad for dealing with textual data. It honestly sucks for everything else, and everything else breaks the pure-logic semantics, so it's not that practical. It's a bit better when used as an embedded DSL from some other language.

5. Learn (delimited) continuations as implemented in Racket. There are other languages which support some form of continuations, and there are even some frameworks which use continuations in these languages (see Nagare web framework for Python or Seaside for Smalltalk). Continuations will give you tools for understanding generators, coroutines, restarts and many other language constructs.