4 ms·
> Last time I checked there were not more parenthesis in lisp than parenthesis+brackets+curly brackets on other languages. This is true a lot of the time. Also
by hellofunk 9y ago
> Last time I checked there were not more parenthesis in lisp than parenthesis+brackets+curly brackets on other languages.
This is true a lot of the time. Also, commas don't exist in Clojure.
So you might have this in a C-like language:
if ((foo > bar) && (bar > boo)) {
doSomething(a,b,c);
} else {
doSomethingElse(d,e,f);
}
And in Clojure:
(if (> foo bar boo)
(doSomething a b c)
(doSomethingElse d e f))
Another interesting side effect is that in C-like lang, one my say that due to precedence rules, (foo > bar) does not need the parenthesis since && is lower precedence. Yet, if you weren't sure, you'd have to take a short break and go look that up to be certain. Most devs will just keep the parenthesis instead of take that little break, or they will write them in anyway for readability. In Lisp, precedence rules are never an issue because all operators and functions are applied the same way. So the parenthesis might seem cumbersome at first, but they quickly make syntax quite a lot simpler.
- DigitalJack 9y agoCommas are whitespace in Clojure. You can use them if you want to, it's just not idiomatic.
- hellofunk 9y agoIt's also not idiomatic to write "doSomething" instead of do-something, but I thought those mentions detracted from the point.
- sd34 9y agoAnd in Scala: 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.
- hellofunk 9y ago> 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.
- simongray 9y ago> Also, what would this even mean: > (> foo bar boo) >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.
- JackFr 9y agoOk. Function call. Got it. So what does (> foo bar boo) mean?
- hellofunk 9y agofoo 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.