4 ms·

> 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 c

> 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
    I'm not interested in differentiating between readability and comprehensability. If I want to work on some code I need to comprehend it. That starts "in the small" with the mechanical aspects of "readability", if you will. Where to draw lines is not relevant. Every aspect to the process of comprehension is important. The "small" aspects are more important than you might think: Because they affect every line of code. Whereas there are fewer instances of the more global aspects to comprehension. Like in a binary tree, where half of the elements are in the lowest level. > you've put parens around "b c" in the "minus" call You have a point. One pair of Irritating Superfluous Parentheses less. > (sum (mul a (minus b c)) > d) Even the consideration to sprinkle such a trivial expression over multiple lines hints at the superiority of a * (b-c) + d. It's just the most straightforward thing to do. No far-fetched argument can change that. I'd love to see eye-tracking data which show the tradeoffs between various syntaxes. The regularity and the simplicty of sexps is of course good for computers, because these can barely associate. Because they can't learn new tricks (they have fixed wiring). But humans have streamlined their languages (which also includes syntax; again, I'm not differentiating here) to their environments since forever. Sexps are also good for abstraction and meta programming. But as we all know abstraction has a cost and there is no point in abstracting an arithmetic expression. And most code, for that matter.

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
  I'm not interested in differentiating between readability and comprehensability. If I want to work on some code I need to comprehend it. That starts "in the small" with the mechanical aspects of "readability", if you will. Where to draw lines is not relevant. Every aspect to the process of comprehension is important. The "small" aspects are more important than you might think: Because they affect every line of code. Whereas there are fewer instances of the more global aspects to comprehension. Like in a binary tree, where half of the elements are in the lowest level. > you've put parens around "b c" in the "minus" call You have a point. One pair of Irritating Superfluous Parentheses less. > (sum (mul a (minus b c)) > d) Even the consideration to sprinkle such a trivial expression over multiple lines hints at the superiority of a * (b-c) + d. It's just the most straightforward thing to do. No far-fetched argument can change that. I'd love to see eye-tracking data which show the tradeoffs between various syntaxes. The regularity and the simplicty of sexps is of course good for computers, because these can barely associate. Because they can't learn new tricks (they have fixed wiring). But humans have streamlined their languages (which also includes syntax; again, I'm not differentiating here) to their environments since forever. Sexps are also good for abstraction and meta programming. But as we all know abstraction has a cost and there is no point in abstracting an arithmetic expression. And most code, for that matter.