5 ms·

And 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 bre

by sd34 9y ago

And 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 ago
  Ok. Function call. Got it. So what does (> foo bar boo) mean?
  - hellofunk 9y ago
    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.
    - JackFr 9y ago
      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.
      - hellofunk 9y ago
        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.
always_good 9y ago
Is there no HN rule about making a fresh account just to incessantly troll a single comment section?

by sd34 9y ago

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 ago
Ok. Function call. Got it. So what does (> foo bar boo) mean?
- hellofunk 9y ago
  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.
  - JackFr 9y ago
    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.
    - hellofunk 9y ago
      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.

always_good 9y ago

Is there no HN rule about making a fresh account just to incessantly troll a single comment section?