If a dev is dumb enough to advocate clojure, I'd be pretty suspect about their coding ability in general. I have yet to work with a decent programmer who liked it.
if(foo > bar && bar > boo) doSomething(a, b, c)
else doSomethingElse(d, e, f)
> Yet, if you weren't sure, you'd have to take a short break and go look that up to be certain.
If you don't know how logic works then why programming? Also, this is not a "complex rule", this is just BASIC LOGIC. As obvious as it can be: read it aloud and you have it.
Also, what would this even mean:
(> foo bar boo)
THIS is what we need to check out because it's everything but obvious.
> So the parenthesis might seem cumbersome at first, but they quickly make syntax quite a lot simpler.
It won't, it'll just make the code monoton and harder to look at.
> If you don't know how logic works then why programming?
Logic and precedence rules are two different things. I know plenty of Haskell devs who frequently consult not just the precedence but also the associativity (right/left) or operators or functions when reading or writing their code. C++ also has a very long list of precedence rules. It's not trivial and many find the lack of these added complexities an advantage in the simple lisp syntax.
> It won't, it'll just make the code monoton and harder to look at.
True, only if you haven't written much lisp.
I suspect you are trolling here, possibly, so maybe my feedback won't matter.
>THIS is what we need to check out because it's everything but obvious.
Any symbol or word in Clojure (or another Lisp) following an open parens is a function call. You literally learn this in the first 2 minutes during the explanation of prefix notation, e.g. (+ 1 2 3) equals 6 or (- 10 1) equals 9. The great thing about Clojure is that > is just a function, not some special notation, so if you are in doubt you can use your editor to click through to the get the function definition (and the actual code). It isn't very hard to train your mind to treat any sequence of (foo x y z) as a function call.
or, put another way, the arguments must be in descending order
It's like instead of writing 1 + 2 + 3 + 4 in Clojure, you write:
(+ 1 2 3 4)
Less characters to type. Because operators are functions, which are always first in a list, normal binary operators like + can take many arguments.
Another benefit of this is function application. If you have a vector/array of numbers and you want to add them all up, just apply them as arguments to +:
(apply + [1 2 3 4 5 6 ...])
If you had an array some-array that had hundreds of numbers, this would be trivial without doing anything other than using the same basic + function:
(apply + some-array)
And since you are expressing the arguments as a single piece of data here, and you can have functions that are much more interesting than +, you can see where this leads.... building up arguments as data, using them in function application. It gets very interesting very fast and the language unlocks a lot of ideas you just don't get in other languages.
I suppose my original point was that its not obvious, because
(+ 1 2 3) behaves differently than (> 1 2 3). Mapping a binary operator to a list is obvious if the type of the result is different than the type of the operands.
I also find 'Less characters to type' a weak argument at the level of a handful of plus signs, but I grant that once you've made the mental leap there is less cognitive overhead. In the '(> x y z)' if I knew to read '>' as 'is descending' the meaning would have been obvious, but reading it as 'greater than' didn't make sense to me.
If you can agree that (> a b) makes easy sense, that a is greater than b (it's the same symbol as a > b, just in a different place), then I don't see how that's any more difficult than (> a b c), which means that b is also greater than c. But then I've been staring at lisp code for years.
If you instead want to compare or sort other values, Clojure offers other functions for that purpose where you can specify in great detail how things should be compared. If > could operate on strings, for example, what would be the expected result? The shorter the string, the "lesser" the value, or the string that starts with the "lower" letter, etc... it's quite ambiguous. You need more than < or > for that kind of comparison.
It means, literally: call a function named '>' and pass it the three arguments specified. That's it.
You may ask what does the function > do when called, but that's a different question and has nothing to do with a language's syntax and semantics.
Also, it's exactly the same with non-Lisp languages. If you don't know Python and see a fragment of code like this:
2 ^ 3 ** 3
wouldn't you have to ask the same question, ie. what do the operators `^` and the other one do when used? However, in this case, you need to also ask about the precedence of the operators, which doesn't exist in Lisp.
