Note that for the above effect, it is irrelevant what Lisp you choose. Yes, it also applies to learning any additional language, but because Lisp is a different breed altogether (as opposed to Fortran-derived languages), more value is to be had from the diversity.
I used to be a huge fan of Common Lisp (even wrote my own series of blogs on why I love it a few years ago) -- still use it in my daily work -- but I came to realize that it's not perfect. There are many things that Clojure has improved upon, e.g. consistent accessor methods, shared immutable data structures vs copying, and probably many more once I dive deeper -- there's a reason why even pg started recommending Clojure over CL or Arc.
tl;dr learning a Lisp is highly recommended. It does not matter which flavour. Or just go read SICP.
On the other hand, if you want to write more functionally, CL also now has shared immutable data structures. Check out FSet: http://www.ergy.com/FSet.html
Say what? Are you sure that you don't mean Scheme? CL has LOOP…
Oh gawd. The biggest wart on the language.
Let's just agree that it's controversial :-)
Still the point is, that Common Lisp prefers iteration by loop-like constructs (or higher-order mapping) to recursion, due to the lack of TCO in the standard: DOLIST, DOTIMES, DO, DO*, LOOP, MAPCAR, MAP, ... Many people prefer the design of the ITERATE macro, but LOOP is already included.
The only people who need to worry about TCO are those writing portable libraries. Everyone else can assume it, at least for local calls, which represent 98% of the times that it matters anyway.
Almost. It's just that that many implementations support it (ABCL not) and that the language does not support it. TCO interacts badly with many Lisp language features: dynamic binding, unwind-protect, ...
> Everyone else can assume it, at least for local calls, which represent 98% of the times that it matters anyway.
If the right optimizations settings are set.
I've never understood this claim. I mean, I understand the technical point: that use of dynamic binding or UNWIND-PROTECT creates a barrier in the stack across which TCO cannot be done. But in practice it seems to me a non-issue. I can't recall ever, in 35 years of Lisp hacking, wanting to write a tail-recursive routine that used one of them on each iteration, in such a way as to cause unbounded stack growth. It just doesn't happen, at least not to me.
Maybe that's partly because I try to keep my usage of dynamic binding to a bare minimum. I think some people overuse it.
Btw., Symbolics Genera also did not support TCO. ;-)
I'm well aware that the LispMs did not do TCO -- I owned several (starting with a CADR) and still have an XL1200 rusting in my closet :-)