[hh2222]

Perhaps this is why BASIC originally used LET in the form LET X = X + 1, to imply a calculation rather than equality.

[weinzierl]

The = for assignment is FORTRAN’s fault. In the beginning there was no equality, just assignment, and FORTRAN (being just a FORmula TRANslator after all) made the somewhat dubious decision to use = for that (punch card space being sparse and symbols limited and all).

When FORTRAN gained equality it went for .EQ. out of practicality and necessity. Many others followed suit but used the somewhat more pleasant == instead of .EQ..

But it didn’t have to happen that way. ALGOL decided to stick close to mathematical tradition:

= for equality

:= for assignment ("definition")

While x := x + 1 is still not clean mathematical notation, I think it wouldn’t have riled up OP’s father as much. If he’d squinted enough, he might even have been able to see little indices below the x’s there.

[selcuka]

> ALGOL decided to stick close to mathematical tradition

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

[Doxin]

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.

[selcuka]

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).

[Doxin]

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

[teddyh]

A rumor I heard was that

  x := 4

was chosen because it looks similar to

  x ⇐ 4

[pjmlp]

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.

[jdougan]

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.

[teddyh]

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.

[weinzierl]

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

[badsectoracula]

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

[tandr]

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

[UltraSane]

I would prefer

x is 5

x is x + 5

[layer8]

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

[UltraSane]

Ok. How about

Set x to x + 5

[layer8]

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. ;)

[UltraSane]

I would prefer

X is 5

X is x + 5

[thequux]

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.

[jagged-chisel]

> 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.

[cryo32]

Think that was just to make the parser understand it was an assignment without having to do any lookahead. There was also possibly ambiguous stuff with equality and assingment as they both used =.

[ASalazarMX]

As kids we had the same debate because we were taught algebra before BASIC, and naturally tried to interpret it mathematically. Fortunately, sometimes a kid can explain it better to other kids than an adult, and that was the case.