foo is greater than bar is greater than boo

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.

Since `>` is a function, you can just read the function doc (you can do this by calling (doc >) in the repl):

    user=> (doc >)
    -------------------------
    clojure.core/>
    ([x] [x y] [x y & more])
      Returns non-nil if nums are in monotonically decreasing order,
      otherwise false.

So (> foo bar boo) essentially checks if bar is between foo and boo.

'nums'? Where did that come from? I assume x and y do not have to be nums?

> and < are for numbers, so yes x and y are nums.

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.