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