A rumor I heard was that

  x := 4

was chosen because it looks similar to

  x ⇐ 4

Why not <= then? I'd expect both < and = to be available.

Probably because '<=' is very easily read as "less or equal"? (unless you are joking, of course)

But why? := is perfectly understandable and established notation for definition. You don't get closer assignment without resorting to esoteric notation?

That is indeed the case in Smalltalk.

The Xerox keyboards had the support for ⇐, with its workstation OSes being all graphical based.

When Smalltalk grew beyond Xerox PARC walls, ⇐ turned into :=

You can see this in the original Xerox PARC documents and books for Smalltalk.

In some of the draft versions of ASCII the positions currently taken by underscore and caret were left arrow and up arrow respectively. As late as 1985 I used terminals (LanparScope) the supported the older draft.

All Commodore machines also uses the older ASCII standards, (in addition to filling out the full 8 bit range with various graphics). It’s usually referred to as “PETSCII”, from the original Commodore “PET” series, but PETSCII was also used in the vastly more popular Commodore 64 (and 128) home computers.

I would prefer

X is 5

X is x + 5

How do you feel about ADD 5 TO X GIVING X?

I kid, of course, but "X is x + 5" brings Prolog to mind with all the unification and bidirectionality that implies.

> ADD 5 TO X GIVING X

Grammatically, this would not change X. "...GIVING X" would just return X. Since it's part of the same statement, it seems it should ignore the "ADD 5 TO X" part.

Now, if you'd like to place the result into X, I suggest "ADD 5 TO X" would suffice as the entire statement.

I would prefer

x is 5

x is x + 5

But x isn’t x + 5. If anything, it should be “x becomes x + 5”.

Ok. How about

Set x to x + 5

That’s pretty much COBOL syntax: https://www.ibm.com/docs/en/debug-for-zos/17.0.x?topic=comma...

Except that COBOL doesn’t allow an arithmetic expression there, so you have to write

    COMPUTE X = X + 5.

instead. ;)

> ALGOL decided to stick close to mathematical tradition

And now we have all 3 in Python (=, ==, and :=) which makes me sad.

Splitting = and := in python is very intentional though, It makes writing bugs like this impossible:

    if is_logged_in=True:
        allow_access()

I've got... opinions on the way python separates statements and expressions, but there's some real benefits to it too.

Splitting = and := is intentional, but not for the reason you stated. We could have used := for all assignments from the beginning:

    is_logged_in := True

or

    if is_logged_in := True:

I agree that this would require blurring the statement/expression distinction. You can still do that in a weird way, by disguising your assignment as an expression. This is valid:

    (is_logged_in := True)

The reason it was done that way because := was an afterthought, and making it the assignment operator would have introduced a breaking incompatibility. That lead to having 3 different symbols for 2 use cases (assignment and comparison).

except if := was the default then accidentally typing ":=" instead of "==" would be the easy bug to make.

:= was bolted on after of course, and I think that was a mistake, but no one asked me, nor do I expect anyone to ;P