3 ms·

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

> 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.
- klibertp 11y ago
  > I'm not interested in differentiating between readability and comprehensability. Fair enough, but then please stop using single letter variable names, add type annotations where applicable, provide docstrings and contracts for functions. Comprehensibility is so much more than syntax that I think mixing the two will make for even more interesting, but even less fact-based discussion. > I'd love to see eye-tracking data which show the tradeoffs between various syntaxes. Yeah, that would be very interesting. The thing is, there is no such data available, but you still are convinced that one kind of syntax is better than the other. I'm not - from where I stand the differences and tradeoffs in readability of syntaxes, once you know them equally well, seem too minor to measure. > Even the consideration to sprinkle such a trivial expression over multiple lines No. It's just different way of getting to the same effect. I don't see why would one be worse than the other (splitting things using infix operators vs. splitting things using horizontal and vertical whitespace). Other than that, you completely avoided the familiarity issue. Do you think that we're genetically programmed for reading infix syntax? If not, then it means we need to learn infix syntax just like any other. My question was, would someone not yet exposed to infix propaganda have a harder time learning infix (with precedence rules and resolving ambiguities) or prefix? You also ignored my question about the difference in readability when you are equally well trained in both syntaxes. You can't compare readability of two syntaxes fairly unless you have about equal amount of skill in both. And the fact that readability is influenced by skill is undeniable. So, in other words, are you sure you're as skilled with sexps - that you wrote comparable amount of code - as with infix? Honestly asking.
  - jstimpfle 11y ago
    > Comprehensibility is so much more than syntax Absolutely. It's a tender flower. > No. It's just different way of getting to the same effect. I don't see why would one be worse than the other (splitting things using infix operators vs. splitting things using horizontal and vertical whitespace). It's very important since size matters. Efficiency of encoding and cost of decoding (~ perception) matters. But if you don't think it makes a difference -- fine, you are free to read braille instead of plain text even if you have perfect eyesight. You can also add three layers of parens around each expression if you think that's more regular. > Do you think that we're genetically programmed for reading infix syntax? No. There's this fact that all combinations of basic grammar are represented in natural languages: SVO, SOV, VSO, VOS, OSV, OVS. And then there are some programming languages which don't differentiate between subjects and objects, but go for (OVO), VO, VOO, VOOO... (or concatenative style OV, OOV, OOOV...). Which is great since the goal of formalism is to be "objective". (Note that Object-oriented programming is actually subject-oriented programming from this standpoint. It's not "objective") Instead I say that it is more efficient if syntax is optimized for the common cases. Shorter is better, if the decoding won't produce more cache misses. Infix and symbols don't produce cache misses for the vast majority of humans, in the case of arithmetic (read: mostly sequential, barely tree-shaped) expressions. Sexps are inherently unoptimized for the common cases. They are "optimized for abstraction": for regularity. It is an explicit design goal to not differentiate things which are different "only" on a very concrete level. Instead of content, form is accentuated. This is not suitable for the > 95% of real life software that is just super-concrete and where abstraction has no benefits. I'm sure I have now given 5 to 10 quite plausible examples which support the standpoint that symbols-and-infix arithmetics is good for humans, based on how their mind works. You haven't provided any counter-arguments but just shrunk off everything. But thanks anyway for that. I think I'm satisfied now with the examples that came out. > are you sure you're as skilled with sexps [..] as with infix? No. Never will be. Are you? Show me a Lisp program with more than casual usage of arithmetics and tell my why you consider it readable. By the way, the first google hit I just got for "lisp arithmetic readability" is http://www.dwheeler.com/readable/ http://www.dwheeler.com/readable/

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.

klibertp 11y ago
> I'm not interested in differentiating between readability and comprehensability. Fair enough, but then please stop using single letter variable names, add type annotations where applicable, provide docstrings and contracts for functions. Comprehensibility is so much more than syntax that I think mixing the two will make for even more interesting, but even less fact-based discussion. > I'd love to see eye-tracking data which show the tradeoffs between various syntaxes. Yeah, that would be very interesting. The thing is, there is no such data available, but you still are convinced that one kind of syntax is better than the other. I'm not - from where I stand the differences and tradeoffs in readability of syntaxes, once you know them equally well, seem too minor to measure. > Even the consideration to sprinkle such a trivial expression over multiple lines No. It's just different way of getting to the same effect. I don't see why would one be worse than the other (splitting things using infix operators vs. splitting things using horizontal and vertical whitespace). Other than that, you completely avoided the familiarity issue. Do you think that we're genetically programmed for reading infix syntax? If not, then it means we need to learn infix syntax just like any other. My question was, would someone not yet exposed to infix propaganda have a harder time learning infix (with precedence rules and resolving ambiguities) or prefix? You also ignored my question about the difference in readability when you are equally well trained in both syntaxes. You can't compare readability of two syntaxes fairly unless you have about equal amount of skill in both. And the fact that readability is influenced by skill is undeniable. So, in other words, are you sure you're as skilled with sexps - that you wrote comparable amount of code - as with infix? Honestly asking.
- jstimpfle 11y ago
  > Comprehensibility is so much more than syntax Absolutely. It's a tender flower. > No. It's just different way of getting to the same effect. I don't see why would one be worse than the other (splitting things using infix operators vs. splitting things using horizontal and vertical whitespace). It's very important since size matters. Efficiency of encoding and cost of decoding (~ perception) matters. But if you don't think it makes a difference -- fine, you are free to read braille instead of plain text even if you have perfect eyesight. You can also add three layers of parens around each expression if you think that's more regular. > Do you think that we're genetically programmed for reading infix syntax? No. There's this fact that all combinations of basic grammar are represented in natural languages: SVO, SOV, VSO, VOS, OSV, OVS. And then there are some programming languages which don't differentiate between subjects and objects, but go for (OVO), VO, VOO, VOOO... (or concatenative style OV, OOV, OOOV...). Which is great since the goal of formalism is to be "objective". (Note that Object-oriented programming is actually subject-oriented programming from this standpoint. It's not "objective") Instead I say that it is more efficient if syntax is optimized for the common cases. Shorter is better, if the decoding won't produce more cache misses. Infix and symbols don't produce cache misses for the vast majority of humans, in the case of arithmetic (read: mostly sequential, barely tree-shaped) expressions. Sexps are inherently unoptimized for the common cases. They are "optimized for abstraction": for regularity. It is an explicit design goal to not differentiate things which are different "only" on a very concrete level. Instead of content, form is accentuated. This is not suitable for the > 95% of real life software that is just super-concrete and where abstraction has no benefits. I'm sure I have now given 5 to 10 quite plausible examples which support the standpoint that symbols-and-infix arithmetics is good for humans, based on how their mind works. You haven't provided any counter-arguments but just shrunk off everything. But thanks anyway for that. I think I'm satisfied now with the examples that came out. > are you sure you're as skilled with sexps [..] as with infix? No. Never will be. Are you? Show me a Lisp program with more than casual usage of arithmetics and tell my why you consider it readable. By the way, the first google hit I just got for "lisp arithmetic readability" is http://www.dwheeler.com/readable/ http://www.dwheeler.com/readable/