Coincidentally in async languages like Verilog there is a another assignment operator '<=' which means that the variable won't take the new value until the next clock cycle (or more explicitly the next evaluation of the process block). '=' exists also and has the same meaning as with traditional languages.

Take Erlang for example:

    1> X = 1.
    1
    2> X = 2.
    ** exception error: no match of right hand side value 2

    1> X = 1.
    1
    2> X = X + 1.
    ** exception error: no match of right hand side value 2
    3>    

    1> {X,Y} = {1,2}.
    {1,2}
    2> X.
    1
    3> Y.
    2
    4>

Ken Thompson on why '=' is assignment and '==' the equality check.

It's this kind of mindset that puts me off Go. But I can totally see that many who want a better C getting into Go exactly for reasons like this.

Since in procedural language, assignment is a much more common operation than equality check, it is reasonable to favor "=" over ":=" or even "<-".

EDIT: It's since been changed to "let", "set", "equal" (but still lower-case).

  The operator " = >" (pronounced "heffalump") is 
  convenient for referencing structures that are 
  accessed indirectly. The expression 
  a=>s.x is equivalent to the expression (@a)»s.x.

Wouldn't it be easier to use = for everything and get rid of those weird edge cases?

> A notorious example for a bad idea was the choice of the equal sign to denote assignment. It goes back to Fortran in 1957 and has blindly been copied by armies of language designers. Why is it a bad idea? Because it overthrows a century old tradition to let “=” denote a comparison for equality, a predicate which is either true or false. But Fortran made it to mean assignment, the enforcing of equality. In this case, the operands are on unequal footing: The left operand (a variable) is to be made equal to the right operand (an expression). x = y does not mean the same thing as y = x. Algol corrected this mistake by the simple solution: Let assignment be denoted by “:=”.

> Perhaps this may appear as nitpicking to programmers who got used to the equal sign meaning assignment. But mixing up assignment and comparison is a truly bad idea, because it requires that another symbol be used for what traditionally was expressed by the equal sign. Comparison for equality became denoted by the two characters “==” (first in C). This is a consequence of the ugly kind, and it gave rise to similar bad ideas using “++”, “--“, “&&” etc.

From Good ideas, through the Looking Glass by N. Wirth:

https://www.semanticscholar.org/paper/Good-Ideas%2C-through-...

Whereas Java is all about protecting developers from themselves, Ruby (for example) let's you get away without variable type declaration because at the end of the day, how often do you not know whether a particular variable is a string or an integer? Enough to justify enforcing declaring everything at the outset or receiving errors throughout your code?

That's not to say that those enforcements never make sense. I think that structured languages like Java are better for larger teams where enforcing standards is more important than a smaller team. But there are other ways to do that and a lot of time the rules make development a horrible experience.

Funnily, when Thompson was asked what he would do differently if he were doing it over again, he said, "I'd spell creat with an e."

https://en.wikiquote.org/wiki/Ken_Thompson

int x = 10 int y = x

would read in English as x gets 10, y gets x.

Shortly after that class I took a break from any coding. When I went to another school I saw Softmore and Junior level programmers still struggling with this. I retained the habit of using 'gets'and never had a problem with this.

I sort of disagree with this. Many functional languages pull heavily from lambda calculus and other forms of mathematics. In math, "a = a + 1" isn't the same as "1 = 2". The issue isn't equality, it's that you're trying to rebind a bound variable, which isn't possible.

In other words, rebinding a bound variable is not the same as "1 = 2".

if you want to calculate the output of a function into a data table(which is what early computers were often doing) iterating a variable x over a f(x) = xn + b(with n and b being fixed constants) is exactly how you would do it on paper so it's probably a case of computers emulating applied math rather then simply being pure theory machines.

But really, this is such a pedantic discussion, trying really hard to not get sucked in.

I was told once by a math professor that it is a habit inherited because we use Arabic numbers/maths which were really meant to be read from right to left. Don’t know if the theory has any merit.

In the mid 60's, when I started programming, most programs had to be keypunched. (There was paper tape entry and Dartmouth's new timesharing system using BASIC, but these weren't in very widespread use.) Until 1964, the keypunch machine in use (IBM 026) had a very limited character set. This is the reason that FORTRAN, COLBOL, and LISP programs were written in upper case. Even the fastest "super" computer of the time, the CDC 6600, was limited to 6-bit characters and didn't have lower case letters.

Naturally, symbols like "←" or "⇐" weren't available, but even the characters ":" and "<" were not on the 026 keypunch keyboard and so ":=" or "<-" were much harder to punch on a card.

These early hardware limitations influenced the design of the early languages, and the early programmers all became accustomed to using "=" (or rarely ":=" or SET) as assignment even though "⇐" might have been more logical. The designers of subsequent programming languages were themselves programmers of earlier languages so most simply continued the tradition.

Fun fact: various dialects of BASIC let you optionally put LET before your assignment statements. So the following are equivalent:

    X = 10
    LET X = 10

  X = Y,
  X = 5,
  %% Y = 5 now as well

  ?- append([1,2], Y, [1,2,3]).
  Y = [3].

Since the equal sign is an assertion of truth, and since assertions cause a crash on failure, you can pretty much derive the rest of the language/BEAM characteristics from that.

Although even then it's nice to use different symbols because they are different meanings. I don't like it when a word has different meanings depending on context.

    a <= 1

And if the goal of mathematicians and programmers were the same, this might be a compelling argument. In no sense do I see my programs as giant algorithms, they're machines, and as such require different syntax to construct.

> But mixing up assignment and comparison is a truly bad idea

Then := is also a bad decision. You should use the fully historically supported form of 'let <variable> = <value>'. Both := and == suffer from the fact that if you omit a single character, you change assignment into comparison or vice versa.

It strikes me as a nitpicky argument for it's own sake.

I think that Lisp doesn't even fit well into that table, since putting LET in the first column would implicitly bring in declaration as well, much of the time SET in the second column would be misleading since mutation is so often done implicitly by a looping construct like DO, DOLIST, DOTIMES or whatever (no SET in sight), and there are all sorts of equality tests one could use.

Edit: ok, I see the author has both updated it, and is specifically talking about Lisp 1.5 which does not have the looping constructs. On the other hand, it at least has a bunch of alternatives to SET that probably should be listed as well, like RPLACA, RPLACD, ATTRIB, and so on. I think that even in Lisp 1.5 variables could be declared in different ways to using LET (like rebinding a variable passed in to a function, so the assignment was in invocation).

If you declare a variable, then x = 2; works in Go.

≔ U+2254 COLON EQUALS

and there is also

⩵ U+2A75 TWO CONSECUTIVE EQUALS SIGNS

if you find typing two = characters fatiguing...

iex(1)> x = 1 1 iex(2)> x = 2 2 iex(3)> ^x = 3 (MatchError) no match of right hand side value: 3

Notice the pin operator (^) to achieve the same effect.

  # bad
  if v = array.grep(/foo/)
    do_something(v)
    # some code
  end

  # good
  if (v = array.grep(/foo/))
    do_something(v)
    # some code
  end

[0]: https://github.com/bbatsov/ruby-style-guide#safe-assignment-...

    2 = X.

    {ok, Y} = X = foo().

    1> {X, X} = {1, 1}.
    {1, 1}.
    2> {Y, Y} = {1, 2}.
    ** exception error: no match of right hand side value {1,2}

    drop(X, List) -> drop(X, List, []).

    drop(X, [], Acc) -> lists:reverse(Acc);
    drop(X, [X|Rest], Acc) -> drop(X, Rest, Acc);
    drop(X, [Y|Rest], Acc) -> drop(X, Rest, [Y|Acc]).

But then we get to this line:

> Because it overthrows a century old tradition to let “=” denote a comparison for equality

In what sense is "=" for comparison a century old? Hasn't it been used for "things that are equal" for multiple centuries? If so, and if that's distinct from "for comparison", then isn't for comparison also a new, non-standard use?

Does anyone understand what he's on about in this quote?

"=" means equality in math; a = a + 1 is the same as 1 = 2 because if you subtract a from both sides and add 1 to both sides you get 1 = 2.

Lambda calculus has the concept of binding variables, but it doesn't use "=" for that, it uses application of lambda forms. It's the same idea that's applied in some variants of Lisp, where LET is a macro such that (let ((x 1) (y 2)) ...) expands to ((lambda (x y) ...) 1 2).

The way it plays out is that rebinding is perfectly fine, because it's not really any different from binding in the first place. The same way that

    (let ((x 10))
      (f x)
      (setf x (1+ x))
      (g x))

    ((lambda (x)
       (f x)
       (setf x (1+ x))
       (g x))
     10)

    ((lambda (x)
       (f x)
       ((lambda (x)
          (g x))
        (1+ x)))
     10)

Functions cannot "work" in math if arguments cannot simultaneously be bound to different values.

Recursion is not possible, and so defining computation in terms of recursion goes out the window.

In someone else's code? 100% of the time. I was once a diehard Ruby believer, and I still use it for small programs. But having had the singular displeasure of working on a huge Ruby codebase (pre-JVM Twitter), I have learned, in the hardest possible way, that untyped languages are absolute nightmares when more than one person is involved.