5 ms·

Aren't they? The fact that confusion between = and == is 4th most frequent is quite interesting for example. It's possible to disallow assignments in places whe

Aren't they? The fact that confusion between = and == is 4th most frequent is quite interesting for example. It's possible to disallow assignments in places where comparisons are most likely (expressions that are known to coerce to a boolean), Python does it, with presumed significant productivity benefits (lots of time isn't spent dealing with that common mistake). D can arguably be mitigated by differentiating bitwise operators more them from their logical counterparts (for example by having the logical operators in plain English). Many more are better handled at the editor/IDE level, but this seems like a really interesting read for anyone involved in PL design.

TheOtherHobbes 10y ago
The Alto thread posted a ref to BCPL, and it was interesting that the original symbols for the comparison operators were text: eq, ne, gt, lt. C broke BCPL syntax that was clear, memorable, and consistent and replaced it with a math-like syntax that must have wasted millions of person hours of debugging time in the decades since - for no good reason. Similarly &(pointer address) and &&(logical and) are too close and too easy to typo. Language design really should have considered human factors much more than it did.
- dsp1234 10y ago
  Interestingly, Powershell uses eq, ne, gt, lt, etc for its comparison operators.
  - 13of40 10y ago
    The historical reason behind that is the > and | symbols were used as redirection operators to follow shell conventions so they used -gt and -bor. All of the other operators followed for consistency. There was also a big kerfuffle about statements like "$a = 1" or "$a++" not being able to return values like in C because if they were used stand-alone the return value would be printed out by the host.
  - mkesper 10y ago
    Yes, this always gets me. I don't like perl-style at all. Compare the cognitive load of distinguishing -lt and -le vs. < and <=.
- groovy2shoes 10y ago
  > Similarly &(pointer address) and &&(logical and) are too close and too easy to typo. Not to mention &(bitwise and).
danso 10y ago
I loved doing this in Ruby: if (x = y) x += 10 end (assign y to x and operate on x if x is truthy ) The optional parens reminds me that this is a deliberate assignment. But as someone who now teaches Python, I thank the Python gods who disallowed such syntactic sugar. I've found it impossible to overestimate how difficult it is for beginners to grok "a = b"...and can you blame them, after years for math instruction telling them that that equals sign means something else? (Never mind the clusterfuck that occurs when trying to teach SQL -- which also uses singal equals sign for equality -- in tandem with a scripting language. The cognitive difficulty is so high that I've considered switching to teaching R, which at least has the optional arrow operator, "a <- b"
- jacquesm 10y ago
  That would not pass review with me. Code should be as obvious and simple to read as possible. It doesn't matter whether or not the reader is a beginner or not, what matters is that it reads like it could be a typo. So there is more cognitive overhead than strictly necessary, and quite possible there are bugs hidden in those 'clever' bit that you love so much.
bbcbasic 10y ago
Haskell has a neat solution. There is no assignment operator. (Let bindings are a different thing)

TheOtherHobbes 10y ago

The Alto thread posted a ref to BCPL, and it was interesting that the original symbols for the comparison operators were text: eq, ne, gt, lt. C broke BCPL syntax that was clear, memorable, and consistent and replaced it with a math-like syntax that must have wasted millions of person hours of debugging time in the decades since - for no good reason. Similarly &(pointer address) and &&(logical and) are too close and too easy to typo. Language design really should have considered human factors much more than it did.

dsp1234 10y ago
Interestingly, Powershell uses eq, ne, gt, lt, etc for its comparison operators.
- 13of40 10y ago
  The historical reason behind that is the > and | symbols were used as redirection operators to follow shell conventions so they used -gt and -bor. All of the other operators followed for consistency. There was also a big kerfuffle about statements like "$a = 1" or "$a++" not being able to return values like in C because if they were used stand-alone the return value would be printed out by the host.
- mkesper 10y ago
  Yes, this always gets me. I don't like perl-style at all. Compare the cognitive load of distinguishing -lt and -le vs. < and <=.
groovy2shoes 10y ago
> Similarly &(pointer address) and &&(logical and) are too close and too easy to typo. Not to mention &(bitwise and).

danso 10y ago

I loved doing this in Ruby: if (x = y) x += 10 end (assign y to x and operate on x if x is truthy ) The optional parens reminds me that this is a deliberate assignment. But as someone who now teaches Python, I thank the Python gods who disallowed such syntactic sugar. I've found it impossible to overestimate how difficult it is for beginners to grok "a = b"...and can you blame them, after years for math instruction telling them that that equals sign means something else? (Never mind the clusterfuck that occurs when trying to teach SQL -- which also uses singal equals sign for equality -- in tandem with a scripting language. The cognitive difficulty is so high that I've considered switching to teaching R, which at least has the optional arrow operator, "a <- b"

jacquesm 10y ago
That would not pass review with me. Code should be as obvious and simple to read as possible. It doesn't matter whether or not the reader is a beginner or not, what matters is that it reads like it could be a typo. So there is more cognitive overhead than strictly necessary, and quite possible there are bugs hidden in those 'clever' bit that you love so much.

bbcbasic 10y ago

Haskell has a neat solution. There is no assignment operator. (Let bindings are a different thing)