41 ms·
> Equals is a lie: = ≠ = This has occurred opposite to me while learning Mathematics. As a programmer, who has been learning fundamental mathematics from the p
by psibi 11y ago
> Equals is a lie: = ≠ =
This has occurred opposite to me while learning Mathematics. As a programmer, who has been learning fundamental mathematics from the past year, the whole assignment/equivalence thing screwed me up so many times.
- johncolanduoni 11y agoA good way to look at it is not as two different symbols, but as the difference between a definition and a theorem. So if you are creating a new variable, function, etc. for convenience you assert "x = 5" (or something similar). Since you have no other constraints this variable has to satisfy, this is totally safe. However, if "x" already shows up in one of your formulas you need to be careful because you can't merely assert it is equal to whatever you want.
- danidiaz 11y agoIn pure functional programming, = = = (bindings are unmodifiable, and it's easier to substitute equals for equals). The assignment operator should have been <- or something other than = from the beginning. I wonder if there was some discussion about that, back in the day?
- talaketu 11y agoas it was in algol day. :=
- gaius 11y agoOr in many functional languages you might say something like a <- 5 Which is quite intuitive.
- jsnell 11y agoBack in the day a large proportion of languages used = for equality and something else for assignment. That something else might have been e.g. * := (Algol-style :=, not Go-style). * A non-ASCII arrow character (surprisingly not always a <- 1, but sometimes 1 -> a) * A keyword (SET a TO 1) So yes, there was certainly a lot of discussion about it, but in the end this is also just a minor design detail. It's just an accident of history that we ended up with =- as-assignment being the norm.
- pjc50 11y agoThis is easier in languages which use the "let a = b" verb: mostly functional languages and basic.