3 ms·

"Choosing the equal sign to denote assignment is one notoriously bad example that goes back to Fortran in 1957 and has been copied blindly by armies of language

"Choosing the equal sign to denote assignment is one notoriously bad example that goes back to Fortran in 1957 and has been copied blindly by armies of language designers since. This bad idea overthrows a century-old tradition to let = denote a comparison for equality, a predicate that is either true or false. But Fortran made this symbol 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. Thus, x = y does not mean the same thing as y = x. Algol corrected this mistake with a simple solution: Let assignment be denoted by :=." --Niklaus Wirth (Good Ideas,Through the Looking Glass)

mimixco 7y ago
Lisp, the second oldest language after Fortran, didn't make this mistake. In Lisp, "=" isn't an operator at all. Assignment is (setf x y) and comparison is (eq x y) [and several variants of eq].
- kazinator 7y ago
  Common Lisp and related languages have = as a function: it is a numeric comparison. Like under equalp, (= 1 1.0) yields true. You might think it's superfluous to equalp, but has some virtues of its own, like supporting variadic arguments (= 1 1 1 1) and rejecting non-numeric arguments. eq is often the wrong one to use: two instances of the same number can fail to be eq.
SlowRobotAhead 7y ago
Equals is a verb AND a adjective though. So I disagree it's notoriously bad to use it as assignment. This is a situation solved entirely with = (make these equals) and == (are these equals?). >Thus, x = y does not mean the same thing as y = x. Unless it does, or should. The specfic argument you're arguing here is on that is just a simple syntax. You don't like = for assignment, but I do. You like = for comparison, but I like ==... To be fair === is dumb. You're arguing that point<~(y=value) makes sense, and I'm still not seeing it.
- augustk 7y ago
  But why change the meaning of one of the most common mathematical symbols? Every new generation of programmers must then relearn what "=" means. If you see "=" in a comment you are never really sure what it means, is it assignment or is it the standard mathematical predicate?
  - SlowRobotAhead 7y ago
    It's not changing the meaning at all. You're picking your preferred meaning, and I'm picking mine. Mine happens to be the almost universal standard for programming. Most lines of code are written as true statements. If you understand how a computer actually works at the register level you'd see that x=5; has a result. And it's not 5. It's TRUE. I'm not asking if x equals 5, I'm saying HEY YOU, X IS EQUAL TO 5. I'm telling the computer this is now the truth. 5 is moved into the x RAM location and the result is true, because the CPU is doing what I told it. You're just wrapped up in your semantic view. There is nothing wrong with = for assignment and == for evaluation. Someone would complain if it was the other way around, so just accept this is the standard - or make your own language that "does things right". But.... Just because it isn't the way you like it, doesn't make it wrong.
  - souprock 7y ago
    Most programming languages change the meaning of one of the most common mathematical symbols. There are at least 3 meanings of "X = Y". Pascal: Is X equal to Y? C: Change X, making it equal to Y. Mathematics: X is equal to Y. Those are all valuable in programming. Normally programmers get the mathematical meaning via a feature such as __assume or __builtin_expect or assert. It can be used for optimization. When the constraint is violated, various bad things can happen. The code can run slower, halt with an error message, or behave in an undefined way. Every new generation of programmers starts off expecting the mathematical meaning. I don't know of any programming language which uses it. Ideally that would be fixed, but the change might be difficult for the current generation of programmers. Note that the Pascal meaning can be fairly compatible with the other meanings. The solution is simply to be aware of context. On a line by itself, X=Y makes no sense as an equality test. Within the controlling part of an "if" or loop, assignment need not be supported. That does the job. Alternately, the meaning could change by having a keyword in front for assignment ("let" is popular) and/or for the assertion. So we could distinguish all three meanings with syntax like "if X=Y", "let X=Y", and "assume X=Y".

mimixco 7y ago

Lisp, the second oldest language after Fortran, didn't make this mistake. In Lisp, "=" isn't an operator at all. Assignment is (setf x y) and comparison is (eq x y) [and several variants of eq].

kazinator 7y ago
Common Lisp and related languages have = as a function: it is a numeric comparison. Like under equalp, (= 1 1.0) yields true. You might think it's superfluous to equalp, but has some virtues of its own, like supporting variadic arguments (= 1 1 1 1) and rejecting non-numeric arguments. eq is often the wrong one to use: two instances of the same number can fail to be eq.

SlowRobotAhead 7y ago

Equals is a verb AND a adjective though. So I disagree it's notoriously bad to use it as assignment. This is a situation solved entirely with = (make these equals) and == (are these equals?). >Thus, x = y does not mean the same thing as y = x. Unless it does, or should. The specfic argument you're arguing here is on that is just a simple syntax. You don't like = for assignment, but I do. You like = for comparison, but I like ==... To be fair === is dumb. You're arguing that point<~(y=value) makes sense, and I'm still not seeing it.

augustk 7y ago
But why change the meaning of one of the most common mathematical symbols? Every new generation of programmers must then relearn what "=" means. If you see "=" in a comment you are never really sure what it means, is it assignment or is it the standard mathematical predicate?
- SlowRobotAhead 7y ago
  It's not changing the meaning at all. You're picking your preferred meaning, and I'm picking mine. Mine happens to be the almost universal standard for programming. Most lines of code are written as true statements. If you understand how a computer actually works at the register level you'd see that x=5; has a result. And it's not 5. It's TRUE. I'm not asking if x equals 5, I'm saying HEY YOU, X IS EQUAL TO 5. I'm telling the computer this is now the truth. 5 is moved into the x RAM location and the result is true, because the CPU is doing what I told it. You're just wrapped up in your semantic view. There is nothing wrong with = for assignment and == for evaluation. Someone would complain if it was the other way around, so just accept this is the standard - or make your own language that "does things right". But.... Just because it isn't the way you like it, doesn't make it wrong.
- souprock 7y ago
  Most programming languages change the meaning of one of the most common mathematical symbols. There are at least 3 meanings of "X = Y". Pascal: Is X equal to Y? C: Change X, making it equal to Y. Mathematics: X is equal to Y. Those are all valuable in programming. Normally programmers get the mathematical meaning via a feature such as __assume or __builtin_expect or assert. It can be used for optimization. When the constraint is violated, various bad things can happen. The code can run slower, halt with an error message, or behave in an undefined way. Every new generation of programmers starts off expecting the mathematical meaning. I don't know of any programming language which uses it. Ideally that would be fixed, but the change might be difficult for the current generation of programmers. Note that the Pascal meaning can be fairly compatible with the other meanings. The solution is simply to be aware of context. On a line by itself, X=Y makes no sense as an equality test. Within the controlling part of an "if" or loop, assignment need not be supported. That does the job. Alternately, the meaning could change by having a keyword in front for assignment ("let" is popular) and/or for the assertion. So we could distinguish all three meanings with syntax like "if X=Y", "let X=Y", and "assume X=Y".