I appreciate the idea of density allowing you to "see" the bigger picture better. It's something I value too. But ideally you can find a balance between the bes

I appreciate the idea of density allowing you to "see" the bigger picture better. It's something I value too. But ideally you can find a balance between the best of both worlds. Why in the world would you comment every function if you could just embed the comment into the code? x@>#:'x sort order alphabetically in place does not to me seem substantially different from order = alphaSort(order) When the comment is embedded into the function, the same effect you described (~"because your functions are small, you can throw your comments away with the function "). These variable and function names need not stick around any more than K comments. Ideally, the name only exists for as long as it has utility, and if it has no utility, it is an anonymous function / never stored in a variable. If there is marginal utility in the name, then sure, use a single character placeholder `o=>sort(compareFn)`. As soon as you need to hold onto an idea of a noun (as in a larger mutating reference frame) or a verb (as in any function you want to both compose and reuse), then names become helpful handles for reasoning about the code over time and opportunities for reuse, `alphaSort=sort(alphaCompareFn); sortedOrders=alphaSort(rawOrders)`. If there's no opportunity for reuse or if the function is trivial, THEN eliminate the longer names. The harder part here is the middle area. With very concise code, you can see the whole thing, but with sufficient complexity, you may not be able to hold what "o" is at any given time in your head. With verbose code, the code will read like highly precise English and you are unlikely to be confused about what "alphaSortedOrders" means, but you might lose track of what the larger program is doing. The real problems arise in the middle: is "orders" my sorted or unsorted orders? If it's not concise enough, you can't immediately see it, and if it's not verbose enough, you don't have a handle on what it is you are operating on. --- Verbose code helps for transferomg "comments" across code boundaries, as when looking at the function signature when calling a function. I don't see how this is substantively longer than doing the same thing with a comment, and it provides additional utility for contextualizing chunks of code. When you change the "job" of the code, you change the variable name at the same time. So while within some complex and mutating function you might want "rawSortedOrders", in some other context where you already know what you have, you strive for density. finalizedOrders = rawSortedOrders.map( o=>o.id=guid() ) or finalizedOrders = rawOrders.pipe( sort(localeCompare), map(o=>o.id=guid()) )