I would say that the names we assign to our values are important. If you name the first binding of x well, then I have a better understanding of what was passed to foo and, therefore, a better understanding of what the calculation of the second x means. I think this goes beyond "reusing symbols" in a let binding and on to the philosophy that "every poorly named symbol is a missed opportunity for good semantics and effective communication".

if you're taking x through a series of transformations, then maybe a thread form makes more sense

I don't currently use a form like this, but I've seen it in the wild. A thread form is what I use but sometimes I need to switch the position. I suppose that's what as-> is for.

as-> is great inside -> pipelines since it lets you assign a temporary name to the threaded value and use it in an expression but, in general, I'd follow Sierra's "Do's and Don'ts" and not mix threading macros -- use local bindings instead to make it clearer what you're doing.

Say you have a list of things and you transform them using ->>. Then you want to do something like call set/join on the result. I don't think there is much value in making up a new name to distinguish the joined and pre-joined list.

You are completely right. There can be trivial steps in the process of a calculation which don't merit naming. It comes down to a judgement call for what situations are worthy of adding more names.

That's why I said "in general". Sometimes the code is more readable if you "break the rules".

I rebind names in let... but I always stop and think whether threading or using primes on names might make things more readable (e.g., (let [x y x' (foo z x)] ...)) -- and also whether it's important to deliberately hide x so it can't be accidentally used in subsequent code... ...in the prime-suffix case, both x and x' are available in the body of the let -- would using x instead of x' be an error? Then shadow/hide x so that can't happen.

Hmm, that's an interesting case. I guess it can be used to "hide" things for safety.

if the transformation is chunky, sometimes it's also a good sign to make a function out of it, which also makes it more amenable to the thread macro

(and easier to test etc)

Makes sense. You could take out an extra step or two from them original transformation and make a function out of it. Then you need to make up another name though.

Coming up with a good name for some step or two in a transformation can be hard. I feel like names have a cost that's hard to quantify.

Have you read "Elements of Clojure"? It has a whole chapter on naming...

Oh yeah, I have that chapter bookmarked. Great stuff. I followed some of the other texts it mentions. It's a deep topic. Haven't read the rest of the book though. I probably should based on how good that chapter is.

Yeah, lots of great stuff in the other chapters.

Ok, thanks all!

reading the source of clojure's built-in macros (like defn or ns) my resistance to this pattern has gotten way lower