3 ms·

> 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

> 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
  > 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. I don't think there is a difference in speed between reading "sum" and "+". You don't read the word "sum" letter by letter: you see it as a whole token and your brain recognizes it instantly. > 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). You're talking GUI, which is different than writing and reading code. There are, for instance, much less GUI elements visible on the screen than there are identifiers even in a short snippet of code and there is much more context available for deduction in the code than in the GUI. I don't think the two situations - recognizing GUI features and recognizing and understanding identifiers in the code - are comparable.
  - jstimpfle 11y ago
    Come on. It's totally obvious that the shapes of * and + are much simpler and much more distinct than "sum" and "mul" (which by the way are relatively short and simple examples for words). Humans have excellent shape recognition -- recognizing (and differentiating) a tree and a person happens subconsciously, effortlessly. Interpreting the words "person" and "tree" takes way more effort. Similarly, humans have usually very good spatial sense. If there are persons to the left and to the right of a tree, it is effortless to recognize that they are "separated". > You're talking GUI, which is different than writing and reading code. No. I'm talking perception. > There are, for instance, much less GUI elements visible on the screen than there are identifiers That depends. There are very complex GUIs out there. But let's assume it for a moment. (By the way that typically that means the code is not good (weak cohesion)). > there is much more context available for deduction in the code than in the GUI. That is not supportive of your previous argument: The more identifiers, the less context per identifier. > I don't think the two situations - recognizing GUI features and recognizing and understanding identifiers in the code - are comparable. It's both about perception. It's very, very important that programmers can focus on their work instead of wasting energy building parse trees in their minds, incurring severe "cache misses". Again, take this simple commonplace example: (sum (mul a (minus (b c)) d) a*(b-c) + d If you don't think there's a huge difference I can't help you. I'm sure I need about three seconds to parse the sexp as a tree and figure out what goes with what. Then I have to go back and interpret the operators. Conversely, the infix/symbol operators example I can map out with minimal, and linear, movement of the eyes. In most cases I don't even need to parse it as a tree -- it's almost a sequence. On a good day, it costs me maybe a second to parse the thing and extract the information I need. Another advantage of symbols for arithmetic is that they give a sense of security, because one can intuitively infer that they have "static" meaning. While usually words are reserved for things that change, i.e. mutable variables. Being able to infer non-mutability based on shape alone gives a huge advantage.
    - klibertp 11y ago
      > Come on. It's totally obvious that the shapes of * and + are much simpler and much more distinct than "sum" and "mul" I disagree that it's obvious. Moreover, I don't believe there is a measurable difference between the speed of recognizing "sum" and "+", once you're equally familiar with both. > The more identifiers, the less context per identifier. I don't believe it's that simple, but we're starting to go into semantics (which are part of comprehensibility of code, but not part of it's readability I think). > If you don't think there's a huge difference I can't help you. I think you can help yourself: just go and train yourself in reading prefix notation, like I did. Then get back to this example and then tell me again that there is a huge difference. > I'm sure I need about three seconds to parse the sexp I don't even know how to measure the time I needed to read the sexp, it was that short. And I even instantly realized that you've put parens around "b c" in the "minus" call, which would cause an error in most lisps. > Conversely, the infix/symbol operators example I can map out with minimal, and linear, movement of the eyes. That's why I used newlines and indentation in my example above. To take your example: (sum (mul a (minus b c)) d) This also reads linearly, just in a different order than you expect. This doesn't make it objectively harder or slower to read, it's just unfamiliar to you. Also see my other comment on familiarity: https://news.ycombinator.com/item?id=11180682 https://news.ycombinator.com/item?id=11180682

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
> 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. I don't think there is a difference in speed between reading "sum" and "+". You don't read the word "sum" letter by letter: you see it as a whole token and your brain recognizes it instantly. > 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). You're talking GUI, which is different than writing and reading code. There are, for instance, much less GUI elements visible on the screen than there are identifiers even in a short snippet of code and there is much more context available for deduction in the code than in the GUI. I don't think the two situations - recognizing GUI features and recognizing and understanding identifiers in the code - are comparable.
- jstimpfle 11y ago
  Come on. It's totally obvious that the shapes of * and + are much simpler and much more distinct than "sum" and "mul" (which by the way are relatively short and simple examples for words). Humans have excellent shape recognition -- recognizing (and differentiating) a tree and a person happens subconsciously, effortlessly. Interpreting the words "person" and "tree" takes way more effort. Similarly, humans have usually very good spatial sense. If there are persons to the left and to the right of a tree, it is effortless to recognize that they are "separated". > You're talking GUI, which is different than writing and reading code. No. I'm talking perception. > There are, for instance, much less GUI elements visible on the screen than there are identifiers That depends. There are very complex GUIs out there. But let's assume it for a moment. (By the way that typically that means the code is not good (weak cohesion)). > there is much more context available for deduction in the code than in the GUI. That is not supportive of your previous argument: The more identifiers, the less context per identifier. > I don't think the two situations - recognizing GUI features and recognizing and understanding identifiers in the code - are comparable. It's both about perception. It's very, very important that programmers can focus on their work instead of wasting energy building parse trees in their minds, incurring severe "cache misses". Again, take this simple commonplace example: (sum (mul a (minus (b c)) d) a*(b-c) + d If you don't think there's a huge difference I can't help you. I'm sure I need about three seconds to parse the sexp as a tree and figure out what goes with what. Then I have to go back and interpret the operators. Conversely, the infix/symbol operators example I can map out with minimal, and linear, movement of the eyes. In most cases I don't even need to parse it as a tree -- it's almost a sequence. On a good day, it costs me maybe a second to parse the thing and extract the information I need. Another advantage of symbols for arithmetic is that they give a sense of security, because one can intuitively infer that they have "static" meaning. While usually words are reserved for things that change, i.e. mutable variables. Being able to infer non-mutability based on shape alone gives a huge advantage.
  - klibertp 11y ago
    > Come on. It's totally obvious that the shapes of * and + are much simpler and much more distinct than "sum" and "mul" I disagree that it's obvious. Moreover, I don't believe there is a measurable difference between the speed of recognizing "sum" and "+", once you're equally familiar with both. > The more identifiers, the less context per identifier. I don't believe it's that simple, but we're starting to go into semantics (which are part of comprehensibility of code, but not part of it's readability I think). > If you don't think there's a huge difference I can't help you. I think you can help yourself: just go and train yourself in reading prefix notation, like I did. Then get back to this example and then tell me again that there is a huge difference. > I'm sure I need about three seconds to parse the sexp I don't even know how to measure the time I needed to read the sexp, it was that short. And I even instantly realized that you've put parens around "b c" in the "minus" call, which would cause an error in most lisps. > Conversely, the infix/symbol operators example I can map out with minimal, and linear, movement of the eyes. That's why I used newlines and indentation in my example above. To take your example: (sum (mul a (minus b c)) d) This also reads linearly, just in a different order than you expect. This doesn't make it objectively harder or slower to read, it's just unfamiliar to you. Also see my other comment on familiarity: https://news.ycombinator.com/item?id=11180682 https://news.ycombinator.com/item?id=11180682