"He hadn’t quite internalized left-hand side vs. right-hand side." This is noteworthy.
In mathematics, equality is symmetric (a=b is the same as b=a).
In programming, variable assignment is asymmetric (a=b is not the same as b=a).
Some programming languages recognize this but get the change wrong by changing the equality operator to == or === and always preferring assignment to be =. Some get it right, e.g., := as assignment.
This is a tradeoff of one hard day in your teens ("But but but equals should work both ways! head explodes") and thirty seconds every time you pick up a new language ("Assignment operator is equals? Got it.") versus typing more several dozen or hundred times a day every day for the rest of your professional life.
Yes, but don't overlook the "Let x =" syntax of mathematics. Programming has just dropped the "let". So, really there is a choice to be made about how to resolve that ambiguity in a language parser. Visual Basic has the nice case of A = B = C setting A equal to the boolean expression B = C.
I don't know where I picked this up, but I use asymmetric whitespace around the assignment operator: a= b. It provides a subtle hint that assignment is not equality.
I know that's what it does under the covers, but is there any reason not to think of it as assignment in your head? That's the mental construct I use in my extremely limited Haskell coding, anyway.
As lanaer said, "<-" is really syntax sugar for ">>=" (bind), and could mean a variety of things (including assignment). "=" is binding a variable, as in "let", and is not symmetric. One could argue that a better name for "=" would be "->", as in "case".
In mathematics, equality is symmetric (a=b is the same as b=a).
In programming, variable assignment is asymmetric (a=b is not the same as b=a).
Some programming languages recognize this but get the change wrong by changing the equality operator to == or === and always preferring assignment to be =. Some get it right, e.g., := as assignment.