4 ms·

These two examples are pretty different unless I'm not getting something? The equivalent of the first in Clojure would be (assuming it's js): (doseq [i (ran

These two examples are pretty different unless I'm not getting something? The equivalent of the first in Clojure would be (assuming it's js): (doseq [i (range 3)] (x i) (y i) (z i)) And the equivalent of the Clojure in the second example in js (assuming we had range()) would be: range(3).map(i=>z(y(x(i)))) If you're using a map as a for loop in js you wouldn't have much indication of that either. And no idea how to properly indent these applications. Like this perhaps? range(3).map( i=> z( y( x(i)))) IMO single line is better with x,y,z. But perhaps with longer function names that's what you would do.

roenxi 6y ago
You are correct. If it helps you can imagine that the functions have side effects and always evaluate to their input. Maybe think of it this way: xxxxx { xx xx xx { xx xx } } vs (xxx xx (xx xx xx xx) xx) I can make a pretty safe guess that the first example is implementing something not worse than O(n^2) before accounting for what the individual calls do, or maybe there is some conditional branching. I can make some guesses about how the code works with probably fair accuracy. That would survive even if I took away the {} braces. In the second example there is not a lot that can be deduced. Whether that matters to you influences whether you are happy coding in a lisp. I prefer the lisps, but there are less hints from the shape of the code.
- auganov 6y ago
  Hmmm, well, so if we're talking purely about indentation wrt control structures, I can see the point, maybe. But if we're talking about the ability to eyeball what's going on, I'm not sure... In Clojure if you see a macro (will be highlighted as a different color) followed by something in square brackets you'll know what's up. The little extra syntax Clojure introduced is quite a big game changer to readability vs other lisps. The problem is we can introduce new macros that may behave differently. You don't have that problem in languages without macros. But if you did have macros, brackets and indentation would lose signal too. Conversely if we didn't have user macros in Clojure the standard convention would be a 100% reliable signal too. I mean, I agree in general that people may find C-like languages more readable, but these examples seem rather poor. I can see why some people would find this more readable if (a || (b && (c + 10 == 11))) { doSomething(); } than this (though I still believe this is mostly a cultural difference) (if (or a (and b (= (+ c 10) 11))) (do-something)) But this is about extra syntax not indentation. You can indent both in many different ways. If anything, given the extra syntax, the js snippet has more possible indentations in this case.

roenxi 6y ago

You are correct. If it helps you can imagine that the functions have side effects and always evaluate to their input. Maybe think of it this way: xxxxx { xx xx xx { xx xx } } vs (xxx xx (xx xx xx xx) xx) I can make a pretty safe guess that the first example is implementing something not worse than O(n^2) before accounting for what the individual calls do, or maybe there is some conditional branching. I can make some guesses about how the code works with probably fair accuracy. That would survive even if I took away the {} braces. In the second example there is not a lot that can be deduced. Whether that matters to you influences whether you are happy coding in a lisp. I prefer the lisps, but there are less hints from the shape of the code.

auganov 6y ago
Hmmm, well, so if we're talking purely about indentation wrt control structures, I can see the point, maybe. But if we're talking about the ability to eyeball what's going on, I'm not sure... In Clojure if you see a macro (will be highlighted as a different color) followed by something in square brackets you'll know what's up. The little extra syntax Clojure introduced is quite a big game changer to readability vs other lisps. The problem is we can introduce new macros that may behave differently. You don't have that problem in languages without macros. But if you did have macros, brackets and indentation would lose signal too. Conversely if we didn't have user macros in Clojure the standard convention would be a 100% reliable signal too. I mean, I agree in general that people may find C-like languages more readable, but these examples seem rather poor. I can see why some people would find this more readable if (a || (b && (c + 10 == 11))) { doSomething(); } than this (though I still believe this is mostly a cultural difference) (if (or a (and b (= (+ c 10) 11))) (do-something)) But this is about extra syntax not indentation. You can indent both in many different ways. If anything, given the extra syntax, the js snippet has more possible indentations in this case.