4 ms·

> Using && and || for logical operators in this day and age is just ridiculous No it's not, it takes 10 minutes to learn that && means and and || means or (may

by dbaupp 13y ago

> Using && and || for logical operators in this day and age is just ridiculous No it's not, it takes 10 minutes to learn that && means and and || means or (maybe a little longer to get the hang of it properly), and this knowledge transfers to many programming languages. (This is a little like arguing "we shouldn't use + when English has a perfectly good word 'add'"; symbol reasoning is valuable.)

count 13y ago
'+' is damn near universal. '&&' && '||' !universal.
- dbaupp 13y ago
  They're not universal, but they're essentially so; pretty much everyone who's used C(++), Java, C#, ... has seen && and ||, and knows what it is. And people who've only used languages with 'and' and 'or' will only take a few minutes to get up to speed (they have the option of spending longer complaining about it if they want).
  - anona 13y ago
    I don't think the argument is that people can't understand '&&' and '||', but that using 'and' and 'or' is a better choice.
    - jussij 13y ago
      So what do you do about the bitwise and and or operations. How should they be expressed? Python expresses the bitwise and and or using the & and | characters, the exact same characters as Go. And that also explains why Go chooses to use && and || for and the logical and or operators.
      - anona 13y ago
        The code is much more readable if the bitwise operators do not look almost identical to the logical ones.
  - ak217 13y ago
    > people who've only used languages with 'and' and 'or' will only take a few minutes to get up to speed No. Cognitive overhead. You pay for it every time you parse these words in your brain. You pay for it by reducing the number of nested/combined clauses that you can parse on the fly. (This is far from the only readability issue with Go, by the way, and you're right in that it's among the more superficial ones. The language is designed so well in all ways except the one that matters the most, it hurts.)
    - n1ghtm4n 13y ago
      Thank you for expressing it so eloquently.
    - msluyter 13y ago
      I agree with you, but FWIW, if you're already used to C, then the cognitive overhead of && and || is probably negligible. Given Go's pedigree, that doesn't seem too surprising.
    - beagle3 13y ago
      No, laziness. && is pronounced "and" but actually means "shortcircuit left-to-right-evaluated and". If you're coming from a Pascal (or non-programming) background, you do not assume either left-to-right evaluation order, nor short circuit evaluation. The cognitive overhead is always there, because whether you like to admit it or not, programming is applied math, and exact meaning is very important; e.g.: if a == 0.0 or b/a > 3 then launch_missile(); Without the "cognitive overhead of knowning guaranteed left-to-right + short circuit", this code is wrong. The hypothetical "newbie programmer who can write a working program but has cognitive overhead deciphering &&" is a mythical creature that does not actually exist.
- Ziomislaw 13y ago
  they are, unfortunately you need to have paid attention at school when they taught you logic operators
n1ghtm4n 13y ago
That's 10 minutes where I could be... you know, living my life, man. Everybody knows what + does. You don't have to teach a high schooler that "if A or B" means "if either A or B is true". They just get it. But what the heck does "if A || B {}" mean?
- gizmo686 13y ago
  Actually, you do have to teach most high schoolers (actually most people) what "A or B" means. The common usage reads that as "A xor B"
  - n1ghtm4n 13y ago
    A very good point. I still think it's a big win if it makes it 1% easier for new programmers to understand.
    - cbhl 13y ago
      I actually think "and" and "or" make it 1% more difficult for new programmers because it doesn't implicitly warn them about things like short-circuit evaluation and whatnot. "and" and "or" have a lot of nuances that experienced programmers take for granted that a new programmer won't know until they're taught.
  - Fistandantilus 13y ago
    In English, sure. Not so for Chinese.
RHSeeger 13y ago
Plus, && and || are symbols which makes them stand out from variable names. This is, in my opinion, a benefit. Admittedly, though, I prefer {} to block delimiters over begin/end and their like.

by dbaupp 13y ago

count 13y ago

'+' is damn near universal. '&&' && '||' !universal.

dbaupp 13y ago
They're not universal, but they're essentially so; pretty much everyone who's used C(++), Java, C#, ... has seen && and ||, and knows what it is. And people who've only used languages with 'and' and 'or' will only take a few minutes to get up to speed (they have the option of spending longer complaining about it if they want).
- anona 13y ago
  I don't think the argument is that people can't understand '&&' and '||', but that using 'and' and 'or' is a better choice.
  - jussij 13y ago
    So what do you do about the bitwise and and or operations. How should they be expressed? Python expresses the bitwise and and or using the & and | characters, the exact same characters as Go. And that also explains why Go chooses to use && and || for and the logical and or operators.
    - anona 13y ago
      The code is much more readable if the bitwise operators do not look almost identical to the logical ones.
- ak217 13y ago
  > people who've only used languages with 'and' and 'or' will only take a few minutes to get up to speed No. Cognitive overhead. You pay for it every time you parse these words in your brain. You pay for it by reducing the number of nested/combined clauses that you can parse on the fly. (This is far from the only readability issue with Go, by the way, and you're right in that it's among the more superficial ones. The language is designed so well in all ways except the one that matters the most, it hurts.)
  - n1ghtm4n 13y ago
    Thank you for expressing it so eloquently.
  - msluyter 13y ago
    I agree with you, but FWIW, if you're already used to C, then the cognitive overhead of && and || is probably negligible. Given Go's pedigree, that doesn't seem too surprising.
  - beagle3 13y ago
    No, laziness. && is pronounced "and" but actually means "shortcircuit left-to-right-evaluated and". If you're coming from a Pascal (or non-programming) background, you do not assume either left-to-right evaluation order, nor short circuit evaluation. The cognitive overhead is always there, because whether you like to admit it or not, programming is applied math, and exact meaning is very important; e.g.: if a == 0.0 or b/a > 3 then launch_missile(); Without the "cognitive overhead of knowning guaranteed left-to-right + short circuit", this code is wrong. The hypothetical "newbie programmer who can write a working program but has cognitive overhead deciphering &&" is a mythical creature that does not actually exist.
Ziomislaw 13y ago
they are, unfortunately you need to have paid attention at school when they taught you logic operators

n1ghtm4n 13y ago

That's 10 minutes where I could be... you know, living my life, man. Everybody knows what + does. You don't have to teach a high schooler that "if A or B" means "if either A or B is true". They just get it. But what the heck does "if A || B {}" mean?

gizmo686 13y ago
Actually, you do have to teach most high schoolers (actually most people) what "A or B" means. The common usage reads that as "A xor B"
- n1ghtm4n 13y ago
  A very good point. I still think it's a big win if it makes it 1% easier for new programmers to understand.
  - cbhl 13y ago
    I actually think "and" and "or" make it 1% more difficult for new programmers because it doesn't implicitly warn them about things like short-circuit evaluation and whatnot. "and" and "or" have a lot of nuances that experienced programmers take for granted that a new programmer won't know until they're taught.
- Fistandantilus 13y ago
  In English, sure. Not so for Chinese.

RHSeeger 13y ago

Plus, && and || are symbols which makes them stand out from variable names. This is, in my opinion, a benefit. Admittedly, though, I prefer {} to block delimiters over begin/end and their like.