7 ms·

c = sqrt(aa + bb) (set! c (sqrt (+ (* a a) (* b b))))

by xrange 11y ago

c = sqrt(a*a + b*b) (set! c (sqrt (+ (* a a) (* b b))))

klibertp 11y ago
(define c (sqrt (sum (sqr a) (sqr b)))) Which you read out loud like this: "c is a square root of a sum of two values, squared". Easy to read as you see and easy to understand. This: c = sqrt(a*a+b*b) is way harder to read.
- mahyarm 11y ago
  I think the thing about lisp isn't the fact that it's functions start with a paren. It's the fact it uses function composition to write everything that makes it harder to keep track of. Most languages don't define their functions like this: c = sqrt(a^2+b^2) vs. define(c, sqrt(sum(sqr(a),sqr(b)))) def getMaxValue(numbers): answer = numbers.first() for (i in xrange(numbers.length)): if (numbers[i] > answer): answer = numbers[i] return answer vs. (defun get-max-value (list) (let ((answer (first list))) (do ((i 1 (1+ i))) ((>= i (length list)) answer) (when (> (nth i list) answer) (setf answer (nth i list)))))) if you could only use python functions: defun(get-max-value, [list], let(answer,first(list)), do( (i,1,(1+ i)), (>=(i, length(list)), ans), when( >(nth(i,list),answer), setf(answer,nth(i,list))))) defun(get-max-value, [list], let(answer,first(list)), do( (i,1,(1+ i)), (>=(i, length(list)), ans), when( >(nth(i,list),answer), setf(answer,nth(i,list)))))
  - lispm 11y ago
    The actual Lisp version is: (defun get-max-value (list) (reduce #'max list)) or even (defun get-max-value (list) (loop for element in list maximize element))
    - mahyarm 11y ago
      Not really. We are demonstrating how multiline statements become hard to read in lisp because in practice you can only use function calls to write everything. Any language where you write an entire function as a huge one liner expression with functionality in nested function calls is hard to read. It's the behavior, not the syntax per say. What the actual behavior is doesn't matter as much, even if you can reduce both of them to one liners in many languages. ex: def get-max-value(list) reduce(:max, list) end
      - klibertp 11y ago
        I already mentioned sweet-expressions in another comment. And also, there's one important thing we're forgetting when discussing syntaxes, which is the fact that we very rarely read the code without syntax highlighting, so the examples you posted actually look like this: http://pygments.org/demo/3781004/ http://pygments.org/demo/3781004/ This does change the situation somewhat.
      - lispm 11y ago
        Not really, since Lisp does not only have function calls, but special forms and macros. In actual Lisp practice, one uses macros, special forms and function calls. You seem to have failed to understand the difference. There are two REAL reasons why Lisp is harder to read than some other languages: * the syntax looks and works slightly different and most programmers have been trained to other programmning language syntax. With training, this is less a problem. * Lisp uses a data syntax as the base layer of the programming languages and encodes programs as data. So the syntax of Lisp comes on top of s-expressions. Very few other programming languages are doing that and as a consequence it complicates a few things. The user of Lisp has to understand the effects of code as data. This is something you don't have to understand in Java or Python. It can be learned, but it has to be learned. At the same time, this code as data principle of Lisp gives a lot of power, flexibility and new capabilities. It makes Lisp different and in some way more powerful than Java or Python. The added power comes from easy syntactic meta programming in Lisp, which neither Java nor Python provide. This has also consequences for interactive programming, since programs can be written and manipulated by programs under user control.
  - klibertp 11y ago
    > if you could only use python functions I'm not sure if this is what you're talking about but there actually is a Lisp where you can call Python functions. It's called Hy[1] and I encourage you to take a look, it borrows some good solutions from Clojure, but generally is quite an acceptable Lisp :) [1] http://hylang.org http://hylang.org
- jstimpfle 11y ago
  No. Why do mathematicians not use s-exps but syntax that is much more similar to C? Reading "sum" "mul" etc. takes longer than if you have visual anchors like * +. And infix is an advantage for simple expressions, because they split arguments, where as with sexps you have to parse from left to right and count parens.
  - klibertp 11y ago
    > Why do mathematicians not use Please tell me why should I care. No, really - I'm a programmer, not a mathematician. > Reading "sum" "mul" etc. takes longer than if you have visual anchors like * +. Citation for this? IMO it's exactly the opposite, but I may be wrong. Some kind of reference would be nice. > And infix is an advantage for simple expressions, because they split arguments, where as with sexps you have to parse from left to right and count parens. Ok, so 2 ("sum" vs. "+", 3 vs. 1 char) additional characters are bad, because they take longer to read, but for example 3 additional characters here: (+ a b c d) vs. a + b + c + d are good, because they take longer to read. That's interesting.
    - jstimpfle 11y ago
      >> Reading "sum" "mul" etc. takes longer than if you have visual anchors like * +. > Citation for this? IMO it's exactly the opposite, but I may be wrong. Some kind of reference would be nice. I know it from myself and don't think I have to to provide evidence that by large most people work like this. Reading and interpreting text is just WAY more complex a process and thus much slower than associating a shape with a meaning. For example, application designers have known for a long time that it's important to build a symbolic language (icons etc) because that's just way faster (once you have learned what the symbol means, for example with the help of a tooltip). There's another guy who explained this at length http://c2.com/cgi/wiki?LispLacksVisualCues http://c2.com/cgi/wiki?LispLacksVisualCues Search for "top" throughout the page. > (+ a b c d) vs. a + b + c + d Yes. But as explained in my other comment, that's not optimizing for the common case.
      - klibertp 11y ago
- Houshalter 11y ago
  Imagine you removed a parenthesis at the end. Would you even notice? It's not compact at all, and there are fewer visual cues. Infix notation works better when it is applicable. Limiting the number of parentheses is also best when possible. You can add parentheses and make it less compact if you want. You could theoretically write c=sqrt(axa+bxb) as: c = sqrt( ((a * a) + (b * b))) But that's just ridiculous.
  - klibertp 11y ago
    > It's not compact at all, You are now arguing against parens. You can have mostly prefix syntax without parens, with blocks delimited with indentation only. Scheme's sweet-expressions[1] are one such example. Anyway, please take my example, remove the parens and check if your argument still applies. If it does, then it's down to the function names and your (common) misconception that "+" or "^" is somehow more readable, easier to understand or something than "sum" or "sqr". Where I simply disagree. BTW: why do you insist on using infix syntax for a couple of operators, while you use every other possible operator in a prefix notation and are happy with it? What is the difference between "sqrt" and "-" which makes it ok to use sqrt in prefix form? > Limiting the number of parentheses is also best when possible. No. It's only best if it aids readability. This is something that Lisp does rather well actually - there are many examples of equivalent Java and Clojure expressions where Clojure version has half as many parens. Getting rid of parens for the sake of getting rid of parens is counterproductive. [1] http://srfi.schemers.org/srfi-110/srfi-110.html http://srfi.schemers.org/srfi-110/srfi-110.html
    - Houshalter 11y ago
      Because your version takes up 6 lines! A simple one line expression! And yes you can remove the parentheses, but not only does no one do that, it still takes up 6 lines. And then you have significant whitespace too. >why do you insist on using infix syntax for a couple of operators, while you use every other possible operator in a prefix notation and are happy with it? What is the difference between "sqrt" and "-" which makes it ok to use sqrt in prefix form? Because that's universal and standard for math notation. But also sqrt only takes one argument. If it took two arguments, then it would be perfectly reasonable to add an infix operator for it too. Many languages do add infix operators for everything from combining strings to ANDing booleans, etc, because they are so much more readable.
- AnimalMuppet 11y ago
  If my cup hadn't been empty, you would owe me a new keyboard. What? You were serious? Um, no. Just no. Your way is not easier to read - at least, not for (I would guess) 95% of programmers, and 99% of humans.
  - klibertp 11y ago
    How do you know? Any proof/any scientific source, or is it just lore and how you personally feel about this?
    - AnimalMuppet 11y ago
      I already admitted that it was a guess. But I still think I can defend it. Starting in elementary school, everyone learns to read math notation. By high school, everyone knows what c = sqrt(a*a + b*b) means. The Lisp version may be easier to read for those who have spent enough time using Lisp. That's not the majority of programmers, though, and it's only a tiny minority of the general population. Do you think that, to a non-Lisp programmer, the Lisp version is easier to read? Do you think it is easier to read to a non-programmer who has had high school math? Or is it just easier to read for you?
      - terminalcommand 11y ago
        Learning lisp syntax requires just a very short introduction. In SICP, it is said that they never formally taught lisp at class. The students just pick Lisp up in a matter of weeks.
      - klibertp 11y ago
        > Starting in elementary school, everyone learns to read math notation. By high school, everyone knows what We're either talking about objective readability or personal familiarity. What you say is that, after extensive training for many years, it is easier for people to read notation they were trained to read. This is both true and utterly uninteresting. What is interesting, though, is how much training you need to read prefix and how much training you need to read infix. It's obvious that infix takes more time to learn: operator precedence and things like using "-" in both infix and prefix forms make it objectively more complex than prefix notation. You just forgot how much time you spent learning it. > Do you think that, to a non-Lisp programmer, the Lisp version is easier to read? Do you think it is easier to read to a non-programmer who has had high school math? Again, this is not interesting at all. You're talking familiarity, not readability. Of course, it's easier to read something you've been taught to read. To make this more objective, take an elementary school kid - who wasn't exposed to years long infix propaganda - and check both notations' readability with them. Personally, I learned to read just about any kind of notation used in programming. From my observations, there are only minor differences between the speed of comprehension when using different notations - once you've trained enough. The difference is how much training you need. I can tell you that reading J - an infix language, it's an APL descendant - took me much, much longer to master than reading Lisp.
AnimalMuppet 11y ago
Something nobody has mentioned yet is that, in the C-style version, the precedence rules are eliminating some parentheses. You can't do that in Lisp (except maybe with a macro). But then, in Lisp, you don't have to remember precedence rules. In this example, the advantage is on the C side, because pretty much everybody who knows any math knows that multiplication has precedence, and they can just read that syntax. If you have to go look at the precedence chart in K&R or Stroustrup before you know how to parse the expression correctly, well, then the Lisp approach is probably more efficient...
knughit 11y ago
Yes, whichever ever one you have seen a million times before looks more readable. So?

c = sqrt(a*a + b*b) (set! c (sqrt (+ (* a a) (* b b))))

by xrange 11y ago

c = sqrt(a*a + b*b) (set! c (sqrt (+ (* a a) (* b b))))

(define c (sqrt (sum (sqr a) (sqr b)))) Which you read out loud like this: "c is a square root of a sum of two values, squared". Easy to read as you see and easy to understand. This: c = sqrt(a*a+b*b) is way harder to read.

mahyarm 11y ago
I think the thing about lisp isn't the fact that it's functions start with a paren. It's the fact it uses function composition to write everything that makes it harder to keep track of. Most languages don't define their functions like this: c = sqrt(a^2+b^2) vs. define(c, sqrt(sum(sqr(a),sqr(b)))) def getMaxValue(numbers): answer = numbers.first() for (i in xrange(numbers.length)): if (numbers[i] > answer): answer = numbers[i] return answer vs. (defun get-max-value (list) (let ((answer (first list))) (do ((i 1 (1+ i))) ((>= i (length list)) answer) (when (> (nth i list) answer) (setf answer (nth i list)))))) if you could only use python functions: defun(get-max-value, [list], let(answer,first(list)), do( (i,1,(1+ i)), (>=(i, length(list)), ans), when( >(nth(i,list),answer), setf(answer,nth(i,list))))) defun(get-max-value, [list], let(answer,first(list)), do( (i,1,(1+ i)), (>=(i, length(list)), ans), when( >(nth(i,list),answer), setf(answer,nth(i,list)))))
- lispm 11y ago
  The actual Lisp version is: (defun get-max-value (list) (reduce #'max list)) or even (defun get-max-value (list) (loop for element in list maximize element))
  - mahyarm 11y ago
    Not really. We are demonstrating how multiline statements become hard to read in lisp because in practice you can only use function calls to write everything. Any language where you write an entire function as a huge one liner expression with functionality in nested function calls is hard to read. It's the behavior, not the syntax per say. What the actual behavior is doesn't matter as much, even if you can reduce both of them to one liners in many languages. ex: def get-max-value(list) reduce(:max, list) end
    - klibertp 11y ago
      I already mentioned sweet-expressions in another comment. And also, there's one important thing we're forgetting when discussing syntaxes, which is the fact that we very rarely read the code without syntax highlighting, so the examples you posted actually look like this: http://pygments.org/demo/3781004/ http://pygments.org/demo/3781004/ This does change the situation somewhat.
    - lispm 11y ago
      Not really, since Lisp does not only have function calls, but special forms and macros. In actual Lisp practice, one uses macros, special forms and function calls. You seem to have failed to understand the difference. There are two REAL reasons why Lisp is harder to read than some other languages: * the syntax looks and works slightly different and most programmers have been trained to other programmning language syntax. With training, this is less a problem. * Lisp uses a data syntax as the base layer of the programming languages and encodes programs as data. So the syntax of Lisp comes on top of s-expressions. Very few other programming languages are doing that and as a consequence it complicates a few things. The user of Lisp has to understand the effects of code as data. This is something you don't have to understand in Java or Python. It can be learned, but it has to be learned. At the same time, this code as data principle of Lisp gives a lot of power, flexibility and new capabilities. It makes Lisp different and in some way more powerful than Java or Python. The added power comes from easy syntactic meta programming in Lisp, which neither Java nor Python provide. This has also consequences for interactive programming, since programs can be written and manipulated by programs under user control.
- klibertp 11y ago
  > if you could only use python functions I'm not sure if this is what you're talking about but there actually is a Lisp where you can call Python functions. It's called Hy[1] and I encourage you to take a look, it borrows some good solutions from Clojure, but generally is quite an acceptable Lisp :) [1] http://hylang.org http://hylang.org
jstimpfle 11y ago
No. Why do mathematicians not use s-exps but syntax that is much more similar to C? Reading "sum" "mul" etc. takes longer than if you have visual anchors like * +. And infix is an advantage for simple expressions, because they split arguments, where as with sexps you have to parse from left to right and count parens.
- klibertp 11y ago
  > Why do mathematicians not use Please tell me why should I care. No, really - I'm a programmer, not a mathematician. > Reading "sum" "mul" etc. takes longer than if you have visual anchors like * +. Citation for this? IMO it's exactly the opposite, but I may be wrong. Some kind of reference would be nice. > And infix is an advantage for simple expressions, because they split arguments, where as with sexps you have to parse from left to right and count parens. Ok, so 2 ("sum" vs. "+", 3 vs. 1 char) additional characters are bad, because they take longer to read, but for example 3 additional characters here: (+ a b c d) vs. a + b + c + d are good, because they take longer to read. That's interesting.
  - jstimpfle 11y ago
    >> Reading "sum" "mul" etc. takes longer than if you have visual anchors like * +. > Citation for this? IMO it's exactly the opposite, but I may be wrong. Some kind of reference would be nice. I know it from myself and don't think I have to to provide evidence that by large most people work like this. Reading and interpreting text is just WAY more complex a process and thus much slower than associating a shape with a meaning. For example, application designers have known for a long time that it's important to build a symbolic language (icons etc) because that's just way faster (once you have learned what the symbol means, for example with the help of a tooltip). There's another guy who explained this at length http://c2.com/cgi/wiki?LispLacksVisualCues http://c2.com/cgi/wiki?LispLacksVisualCues Search for "top" throughout the page. > (+ a b c d) vs. a + b + c + d Yes. But as explained in my other comment, that's not optimizing for the common case.
    - klibertp 11y ago
Houshalter 11y ago
Imagine you removed a parenthesis at the end. Would you even notice? It's not compact at all, and there are fewer visual cues. Infix notation works better when it is applicable. Limiting the number of parentheses is also best when possible. You can add parentheses and make it less compact if you want. You could theoretically write c=sqrt(axa+bxb) as: c = sqrt( ((a * a) + (b * b))) But that's just ridiculous.
- klibertp 11y ago
  > It's not compact at all, You are now arguing against parens. You can have mostly prefix syntax without parens, with blocks delimited with indentation only. Scheme's sweet-expressions[1] are one such example. Anyway, please take my example, remove the parens and check if your argument still applies. If it does, then it's down to the function names and your (common) misconception that "+" or "^" is somehow more readable, easier to understand or something than "sum" or "sqr". Where I simply disagree. BTW: why do you insist on using infix syntax for a couple of operators, while you use every other possible operator in a prefix notation and are happy with it? What is the difference between "sqrt" and "-" which makes it ok to use sqrt in prefix form? > Limiting the number of parentheses is also best when possible. No. It's only best if it aids readability. This is something that Lisp does rather well actually - there are many examples of equivalent Java and Clojure expressions where Clojure version has half as many parens. Getting rid of parens for the sake of getting rid of parens is counterproductive. [1] http://srfi.schemers.org/srfi-110/srfi-110.html http://srfi.schemers.org/srfi-110/srfi-110.html
  - Houshalter 11y ago
    Because your version takes up 6 lines! A simple one line expression! And yes you can remove the parentheses, but not only does no one do that, it still takes up 6 lines. And then you have significant whitespace too. >why do you insist on using infix syntax for a couple of operators, while you use every other possible operator in a prefix notation and are happy with it? What is the difference between "sqrt" and "-" which makes it ok to use sqrt in prefix form? Because that's universal and standard for math notation. But also sqrt only takes one argument. If it took two arguments, then it would be perfectly reasonable to add an infix operator for it too. Many languages do add infix operators for everything from combining strings to ANDing booleans, etc, because they are so much more readable.
AnimalMuppet 11y ago
If my cup hadn't been empty, you would owe me a new keyboard. What? You were serious? Um, no. Just no. Your way is not easier to read - at least, not for (I would guess) 95% of programmers, and 99% of humans.
- klibertp 11y ago
  How do you know? Any proof/any scientific source, or is it just lore and how you personally feel about this?
  - AnimalMuppet 11y ago
    I already admitted that it was a guess. But I still think I can defend it. Starting in elementary school, everyone learns to read math notation. By high school, everyone knows what c = sqrt(a*a + b*b) means. The Lisp version may be easier to read for those who have spent enough time using Lisp. That's not the majority of programmers, though, and it's only a tiny minority of the general population. Do you think that, to a non-Lisp programmer, the Lisp version is easier to read? Do you think it is easier to read to a non-programmer who has had high school math? Or is it just easier to read for you?
    - terminalcommand 11y ago
      Learning lisp syntax requires just a very short introduction. In SICP, it is said that they never formally taught lisp at class. The students just pick Lisp up in a matter of weeks.
    - klibertp 11y ago
      > Starting in elementary school, everyone learns to read math notation. By high school, everyone knows what We're either talking about objective readability or personal familiarity. What you say is that, after extensive training for many years, it is easier for people to read notation they were trained to read. This is both true and utterly uninteresting. What is interesting, though, is how much training you need to read prefix and how much training you need to read infix. It's obvious that infix takes more time to learn: operator precedence and things like using "-" in both infix and prefix forms make it objectively more complex than prefix notation. You just forgot how much time you spent learning it. > Do you think that, to a non-Lisp programmer, the Lisp version is easier to read? Do you think it is easier to read to a non-programmer who has had high school math? Again, this is not interesting at all. You're talking familiarity, not readability. Of course, it's easier to read something you've been taught to read. To make this more objective, take an elementary school kid - who wasn't exposed to years long infix propaganda - and check both notations' readability with them. Personally, I learned to read just about any kind of notation used in programming. From my observations, there are only minor differences between the speed of comprehension when using different notations - once you've trained enough. The difference is how much training you need. I can tell you that reading J - an infix language, it's an APL descendant - took me much, much longer to master than reading Lisp.

AnimalMuppet 11y ago

Something nobody has mentioned yet is that, in the C-style version, the precedence rules are eliminating some parentheses. You can't do that in Lisp (except maybe with a macro). But then, in Lisp, you don't have to remember precedence rules. In this example, the advantage is on the C side, because pretty much everybody who knows any math knows that multiplication has precedence, and they can just read that syntax. If you have to go look at the precedence chart in K&R or Stroustrup before you know how to parse the expression correctly, well, then the Lisp approach is probably more efficient...

knughit 11y ago

Yes, whichever ever one you have seen a million times before looks more readable. So?