This doesn't seem like a useful comparison, analysis or conclusion. Clojure is philosophically a Lisp, but as others have pointed out, it isn't usefully the same language as any other Lisp that preceded it or exists today. If this particular example is useful to people who might otherwise think they could reuse existing Lisp code, then I suppose it's saved some effort, but that just seems like a straw man.
Either way, if you get the terminal condition of a recursive function wrong, you will blow the stack. It's true Clojure isn't built to do TCO, but that's a non-sequitur. The idea that you don't typically use recursion in Clojure is ridiculous - for is a macro, it's syntactic sugar over Clojure's recursion primitives, loop and recur. Even if you didn't want to use that, change the nil? check to empty? and it works. I'm not going to claim that Clojure's list/sequence semantics are necessarily the cleanest (the empty _sequence_ in Clojure is nil, an empty list/vector/set etc is not), but they're not hard to learn if you make any effort at all. Again, your existing Lisp experience may or may not help you understand Clojure's data structures, but I am surprised that this is a surprise to anybody.
In practice recursion is not something that you use that often I think. I've always seen it as a low level construct. The filter/map/reduce idiom or, alternatively, list comprehensions get you a long way.
Not to say recursion is not important. Without it lambda calculus is not Turing complete. But Clojure does provide explicit TCO. Saying this is a big difference is excessive IMHO.
Either way, if you get the terminal condition of a recursive function wrong, you will blow the stack.
Not in Common Lisp. The last time I tried to show someone how well recursion worked in a typical Common Lisp implementation, I crashed Firefox trying to paste the result of a naive factorial function into a text buffer. Stack depth limits in other languages are often arbitrary.
I suppose what I ought to have said is that very few programming languages can completely protect you from your own logic errors. It was not hard for Giles to discover the error in his code, but he still blamed the language for it.
Yeah, I got to the following line and stopped reading:
> First, this code assumes that (if (null list1)) in Common Lisp will be equivalent to (if (nil? list1)) in Clojure, but Clojure doesn't consider an empty list to have a nil value.
That sentence makes it very clear the writer either hasn't been arsed to read through even one Clojure tutorial or is being intentionally dense. If they have an educated opinion, great, but I have no patience for this level of ignorance, especially if it's feigned ignorance.
Either way, if you get the terminal condition of a recursive function wrong, you will blow the stack. It's true Clojure isn't built to do TCO, but that's a non-sequitur. The idea that you don't typically use recursion in Clojure is ridiculous - for is a macro, it's syntactic sugar over Clojure's recursion primitives, loop and recur. Even if you didn't want to use that, change the nil? check to empty? and it works. I'm not going to claim that Clojure's list/sequence semantics are necessarily the cleanest (the empty _sequence_ in Clojure is nil, an empty list/vector/set etc is not), but they're not hard to learn if you make any effort at all. Again, your existing Lisp experience may or may not help you understand Clojure's data structures, but I am surprised that this is a surprise to anybody.