4 ms·

I have some experience in computer language design. The issue here is that `a==b==c` expression is magical - that is it does not follow from extending compariso

I have some experience in computer language design. The issue here is that `a==b==c` expression is magical - that is it does not follow from extending comparison binary operator. Specifically, `==` is a binary operator that that compares an expression before and after and returns a boolean. In this case, A==B==C is a trinary comparison operator. This is normally ok, except it's rare and the symbol it is using is overloaded with binary comparison operator, so the people will be confused. This actually gets weirder - in python you can make an arbitrary long comparison operator - it's called comparison chaining - https://www.programiz.com/online-compiler/6uyqb52IVH8if https://www.programiz.com/online-compiler/6uyqb52IVH8if . It works with a lot of operators - https://www.geeksforgeeks.org/chaining-comparison-operators-python/ https://www.geeksforgeeks.org/chaining-comparison-operators-... Once you know how it works and are used to it, I think it makes the code easier to parse... but there are heavy downsides. For example, it's not clear how short circuiting works. I've used python a bunch and logically I expect ```side_effect3()``` to not be evaluated if results of 1 and 2 are not equal: ```side_effect1() == side_effect2() == side_effect3()```. However, I do not know that for sure, while in other languages I would be able to reason about this from basic principles.

Ukv 2y ago
> the symbol it is using is overloaded with binary comparison operator, so the people will be confused I think most people would expect expressions like `5 < x < 10` to work as they do in math, without necessarily thinking about it in terms of being an overloaded binary operator. The result in other languages that `5 < 12 < 10` = `true < 10` = `true` is more surprising, just that we've (perhaps by being bitten by it early on) gotten used to it.
- redditor98654 2y ago
  Yeah, but should that math equivalence hold for programming though? Programming is different. x=x+1 is perfectly legal in programming but does not make sense in algebra math and could confuse mathematicians.
  - lordnacho 2y ago
    Maybe = should actually be := which it is in some languages? x = x + 1 sounds wrong if you are in math mode x := x + 1 is uncommon in math and you can take it to mean "set x to whatever is currently x, plus one" But it's also true that you need to be able to accept certain conventions when changing fields.
  - Ukv 2y ago
    > should that math equivalence hold for programming though? It's not a hard rule that overrides all other considerations, but I do think Python's choice to follow math is the right decision here. I'd claim if you teach someone `<` then show them `5 < x < 10` for the first time, they're far more likely to go with the math interpretation than the C one. That is, beyond the fact that someone's familiarity with math reinforces this intepretation, the reason for math using this interpretation in the first place is because it aligns with intuition. It's also just pretty useful. It's common to want to check if a number is between some bounds, like `0 <= i < len`, or that multiple things are equal. In cases where you really do want the C behavior, I'd say you should already write that as `(x == y) == z` for clarity anyway, regardless of whether the language lacks chaining and thus lets you omit the parentheses.
sampo 2y ago
> it's not clear how short circuiting works It is clear if you read the docs. https://docs.python.org/3/reference/expressions.html#comparisons https://docs.python.org/3/reference/expressions.html#compari... https://docs.python.org/3/reference/expressions.html#boolean-operations https://docs.python.org/3/reference/expressions.html#boolean...
- _w1tm 2y ago
  Is “let me check the docs” an appropriate thing to say in an interview setting?
  - natebc 2y ago
    yes.
  - acdha 2y ago
    It’s what you’d do on the job, right? A place which dings you for checking your work is broken. I’d expect a raised eyebrow if it was some very basic question about something you’ve claimed to be an expert in but given how many, many bugs over the years stem back to confusion about order of evaluation I would consider it a minor plus if someone said “I think I know but I want be certain”, and a major one if they paired that with mention of defensive coding practices like adding tests covering cases where it’d matter and structuring the code so there are no side effects hidden in the test (e.g. the code as written is fine but if it was f1() == f2() == f3() I’d probably write it as a clearer multi-line if block when there are side effects to those calls to make obvious when I’m intentionally not doing them in every case).
  - bityard 2y ago
    It absolutely is.
  - ljm 2y ago
    I'd prefer a candidate to check the docs or look something up if they were unsure, because that would also provide useful information to me as an interviewer. Although I'd also want that benefit of the doubt for myself. I'm quite familiar with how Ruby handles collections, for example, but if I tried to use `slices.Collect` in Go the same way as `Enumerable#collect` in Ruby I'd end up stuck and would need clarification.
phkahler 2y ago
>> but there are heavy downsides. For example, it's not clear how short circuiting works. Opinion: Code that depends on side effects like that in a conditional is BAD. It is not an optimization, it's an obfuscation.
ashu1461 2y ago
Agree, also by reasoning from basic principles adding extra brackets ( ) should not change the output result - at least this is what our brain is programmed to believe, but in the case of chained operations it will. Example (a==b)==c would be different from a==b==c

Ukv 2y ago

> the symbol it is using is overloaded with binary comparison operator, so the people will be confused I think most people would expect expressions like `5 < x < 10` to work as they do in math, without necessarily thinking about it in terms of being an overloaded binary operator. The result in other languages that `5 < 12 < 10` = `true < 10` = `true` is more surprising, just that we've (perhaps by being bitten by it early on) gotten used to it.

redditor98654 2y ago
Yeah, but should that math equivalence hold for programming though? Programming is different. x=x+1 is perfectly legal in programming but does not make sense in algebra math and could confuse mathematicians.
- lordnacho 2y ago
  Maybe = should actually be := which it is in some languages? x = x + 1 sounds wrong if you are in math mode x := x + 1 is uncommon in math and you can take it to mean "set x to whatever is currently x, plus one" But it's also true that you need to be able to accept certain conventions when changing fields.
- Ukv 2y ago
  > should that math equivalence hold for programming though? It's not a hard rule that overrides all other considerations, but I do think Python's choice to follow math is the right decision here. I'd claim if you teach someone `<` then show them `5 < x < 10` for the first time, they're far more likely to go with the math interpretation than the C one. That is, beyond the fact that someone's familiarity with math reinforces this intepretation, the reason for math using this interpretation in the first place is because it aligns with intuition. It's also just pretty useful. It's common to want to check if a number is between some bounds, like `0 <= i < len`, or that multiple things are equal. In cases where you really do want the C behavior, I'd say you should already write that as `(x == y) == z` for clarity anyway, regardless of whether the language lacks chaining and thus lets you omit the parentheses.

sampo 2y ago

> it's not clear how short circuiting works It is clear if you read the docs. https://docs.python.org/3/reference/expressions.html#comparisons https://docs.python.org/3/reference/expressions.html#compari... https://docs.python.org/3/reference/expressions.html#boolean-operations https://docs.python.org/3/reference/expressions.html#boolean...

_w1tm 2y ago
Is “let me check the docs” an appropriate thing to say in an interview setting?
- natebc 2y ago
  yes.
- acdha 2y ago
  It’s what you’d do on the job, right? A place which dings you for checking your work is broken. I’d expect a raised eyebrow if it was some very basic question about something you’ve claimed to be an expert in but given how many, many bugs over the years stem back to confusion about order of evaluation I would consider it a minor plus if someone said “I think I know but I want be certain”, and a major one if they paired that with mention of defensive coding practices like adding tests covering cases where it’d matter and structuring the code so there are no side effects hidden in the test (e.g. the code as written is fine but if it was f1() == f2() == f3() I’d probably write it as a clearer multi-line if block when there are side effects to those calls to make obvious when I’m intentionally not doing them in every case).
- bityard 2y ago
  It absolutely is.
- ljm 2y ago
  I'd prefer a candidate to check the docs or look something up if they were unsure, because that would also provide useful information to me as an interviewer. Although I'd also want that benefit of the doubt for myself. I'm quite familiar with how Ruby handles collections, for example, but if I tried to use `slices.Collect` in Go the same way as `Enumerable#collect` in Ruby I'd end up stuck and would need clarification.

phkahler 2y ago

>> but there are heavy downsides. For example, it's not clear how short circuiting works. Opinion: Code that depends on side effects like that in a conditional is BAD. It is not an optimization, it's an obfuscation.

ashu1461 2y ago

Agree, also by reasoning from basic principles adding extra brackets ( ) should not change the output result - at least this is what our brain is programmed to believe, but in the case of chained operations it will. Example (a==b)==c would be different from a==b==c