Why Does “=” Mean Assignment? (hillelwayne.com)

Languages borrowing the syntax don't need to follow its logical consistency. I just thought it was an interesting anecdote.

The r-value is ephemeral it doesn't exist once the statement ends.

Implementing a cryptosystem is one of the first things for 10 year olds with no prior programming experience???? That seems intense compared to Scratch, etc.

I'd have thought, not being a programmer, that drop was used because whilst the access and relations with the drop-ed table are updated the table isn't necessarily deleted.

Drop updates the logical structure without necessarily acting on the physical storage in a way commensurate with "deletion". You can this drop a million tuple table in a ms (less I expect) whilst deletion would take far, far longer (of the order of a million-times longer).

/guessing

It does according to your next sentence.

The key isn't whether you use := or =, it's whether you allow assignment in expressions.

My advice: don't allow assignment in expressions. To me, it's like the case-sensitive issue: the language designers think it's a useful feature, but it actually works against most developers.

  my_instance vs myinstance

  things vs THINGS

Why not 'is'?

Fun fact, R also has -> (assign to the RHS instead of LHS), and "super-assignment" <<- and ->>, and also can use = sometimes too (and I think has different semantics). Yay R.

Common in Pre-Python pseudo code and algorithms.

In the original Smalltalk implementation, the character corresponding to _ in ASCII was a left facing arrow, which Smalltalk used for assignment at the time.

From the article:

> Looking at this as a whole, = was never “the natural choice” the assignment operator. Pretty much everybody used := for assignment instead, possibly because = was so associated with equality. Nowadays most languages use = entirely because C uses it, and we can trace C using it to CPL being such a clusterfuck.

FORTRAN was far from the first high level language.

Plankalkül for example was out a decade earlier and used →. EX:

  P1 max3 (V0[:8.0],V1[:8.0],V2[:8.0]) → R0[:8.0]

https://en.wikipedia.org/wiki/Plankalk%C3%BCl

So, there really was a lot of languages out there, but := was fairly common because it was easy to parse and type.

> "=" was used in Fortran.

And most BASICs, though some (most?) required the keyword LET to introduce an assignment, as well.

Rutishauser might have gotten it from Konrad Zuse's Plankalkül, which used the right double arrow ⇒, which looks a little like =.

Plankalkül had the order and the assignment reversed relative to C, so to increment a variable Z1, you'd write:

    | Z + 1 ⇒ Z
  V | 1       1
  S | 1·n 1·n 1·n

(The first line is the 'main line'; Z stands for Zwischenwert, i.e. "intermediate value". The second line is the 'value line', which contains the indices of the variables -- to store Z1 + 1 in a new variable Z2, you'd replace the second 1 with 2. The third line contains Struktur-Indizes.)

Pascal as well, and its descendents like Modula-2

The shorthand I use for "becomes the same as" is "gets".

I was taught to read it as “takes the value of”.

Technical papers are written using '<-' in pseudocode because the papers likely use '=' elsewhere to assert equality in a mathematical statement and they want to avoid confusion.

The syntax of C is a thing of beauty. The decision to use = for assignment and == for equality was natural, since assignment is more common than equality testing; similarly, articles are usually short words in natural languages. Algol 68 and Pascal got this wrong, and where are they now?

"<-" is used for assignment in F#, though variable binding is "=", so:

    let mutable x = 4   // x is equal to 4
    x <- 7              // x is equal to 7

Yeah but this introduced an easy path for errors. You could mean to write `==` and instead write `=` and it'll work fine in C in practically all locations (even as conditions of if-statements). Using `:=` could have likely alleviated this error to a noticeable degree, if not entirely.

in primary school the focus in expressions involving = is reduction more than equality:

    2 + 2 = 4
    <n terms> = <constant>

I don't recall teacher showing you equalness through stupid but important ideas:

    2 + 2 = 2 + 2
    2 + 2 = 2 + 1 + 1

all these are equal, and it's important later on when expression, with variables, aren't reducible to a constant but to another expression which is equal to the other one. IMO it would help a lot for people to try to simplify a problem into a known identity or interesting form (for instance the 'trick' of adding and subtracting one to get closer to binomial formula or other)

> There are better places if you just want to talk about yourself.

hmm, I don't agree with what you are implying defines acceptable comment content on HN. There are many if not a majority of comments highly rated on HN which are highly personal that necessarily talk about themselves, it's part of what makes those comments interesting, if we all commented like wikipedia articles it would be a dull place indeed. My comment maybe flawed in the eyes of other HN readers, but not for the reason you have highlighted.

In my case it's is both personal and relevant but to be honest - not interesting or insightful which is probably why someone mean enough gave me a downvote... but then afterwards I broke the "first rule of fight club" which on HN is equivalent to throwing yourself to the wolves, I accept that, and also can't help it, it's just my nature, I don't self censor for points.

Come now, that's not nice. It's fine to talk about one's experiences on HN. That's what people do in conversation.

Also Visual Basic.

Yeah, Prolog's unification operator really blows your mind the first few times you experience it. You left the best part out of that last example:

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

    X = [1],
    Y = [2, 3] ;

    X = [1, 2],
    Y = [3] ;

    X = [1, 2, 3],
    Y = [] ;

    false.

(a few newlines added for clarity)

I don't think I've heard of this before; I'd love to watch it if you have a link!

Thanks for sharing. Enjoyed watching (from the link below). Well done!

I like the '=' as an assertion idea. That is, it's like running code with assertions turned on. Never thought about it that way but it makes good sense.

Also stealing your idea of "rebootable code" :-)

Though it's true that compilers usually turn assignments into SSA, that's not really the same as what parent was referring to. Static single assignment has the same semantics as normal C-style assignments. The parent was referring to assignments that have (Erlang's) pattern match semantics.

Also, there's a simple counterexample. You can have static single assignment that has dynamic multiple assignment (e.g. within a loop construct). Under the pattern-matching semantics, evaluating the assignment (or rather the pattern match) a second time could fail, whereas an assignment always succeeds.

I've used Erlang but not Elixir. Having an additional optional "pin" operator sounds like a bad idea, just piling on complexity. You can't mess up with the Erlang syntax.

To illustrate how close Erlang syntax is to Prolog, here is drop/3 in Prolog:

    drop(X, List, Result) :- drop(X, List, [], Result).

    drop(_, [], Acc, Result) :- reverse(Acc, Result).
    drop(X, [X|Rest], Acc, Result) :- drop(X, Rest, Acc, Result).
    drop(X, [Y|Rest], Acc, Result) :- dif(X, Y), drop(X, Rest, [Y|Acc], Result).

I only had to make a few syntactic changes to the original program to obtain a Prolog predicate from it. The most significant change is that I use an additional argument to hold the original function's return value. An important consequence of the resulting relational nature is that this can answer quite general queries.

For example, we can ask: What are possible solutions Ls that arise when we drop X from the single-element list [A] ?

    ?- drop(X, [A], Ls).
    X = A,     Ls = [] ;
    dif(X, A), Ls = [A].

We see that there are two possible answers: One where X is A, and hence the result is the empty list []. And the other where X is different from A, as indicated by dif(X, A).

Even more generally, we can systematically enumerate all conceivable solutions for all list lengths:

    ?- length(Ls0, _), drop(X, Ls0, Ls).
    Ls0 = Ls, Ls = [] ;
    Ls0 = [X],
    Ls = [] ;
    Ls0 = Ls, Ls = [_586],
    dif(X, _586) ;
    Ls0 = [X, X],
    Ls = [] ;
    Ls0 = [X, _598],
    Ls = [_598],
    dif(X, _598) ;
    etc.

This uses iterative deepening to generate all possible answers.

    ?- drop(X, [a,b,c], [a,c]).
    X = b ;
    false.

    ?- drop(X, [a,b,c], [a,b,c]).
    dif(X, c),
    dif(X, b),
    dif(X, a).

    ?- drop(X, [a,b,c], _).
    X = a ;
    X = b ;
    X = c ;
    dif(X, c),
    dif(X, b),
    dif(X, a).

I have mixed feelings on this. On one hand I did want this notation while learning haskell. Partly because there are a bunch of places in haskell's type system where repeating a variable implicitly gives equality constraints.

On the other hand something like

    drop _ [] = []
    drop x (y:xs)
        | x == y = drop x xs
        | otherwise = y : drop x xs

is often more readable at a glance to me since I don't have to parse variable names to see control flow structures.

Also, in statically typed languages what happens if equality doesn't work for a value.

    drop _ [] = []
    drop x (x:xs) = drop x xs
    drop x (y:xs) = y : drop x xs

    drop :: Eq a => a -> [a] -> [a]

I could imagine by destructuring he means e.g. unapply in Scala: https://docs.scala-lang.org/tour/extractor-objects.html

    > let {a,b} = {a: 1, b: 2}
    > a
    1
    > b
    2

https://clojure.org/guides/destructuring

Basically it means that you can assign several variables at once, by asssigning a complex value to an aproprietly structured literal with variables as placeholders.

In pseudojavascript, let's say you got this from some API:

    var someList = [1, 2, 3, 4];
    var someMap = { name: "John Smith",
                    age: 20,
                    cars: [{ id: "AAA-1111", model: "Ford T"},
                           { id: "AAA-1112", model: "Mercedes Benz"}] }

And you want to extract useful data for your code quickly. In languages with destructuring you can do sth like this:

    var [x, y & rest] = someList; //x==1, y==2, rest == [3, 4]
    var { "name": name,
          "age": age,
          "cars": [ {"id": firstCarId, "model": firstCarModel}
                  & restOfTheCars ]
        } = someMap;

And the language will put the correct values in your variables name, age, firstCarId, firstCarModl, restOfTheCars.

    > let a = [1,2,3]
    undefined
    > [x,y,z] = a
    Array(3) [ 1, 2, 3 ]
    > x
    1
    > y
    2
    > z
    3

The other responses captured the essence of what it is, but I thought it might be interesting to briefly discuss how Erlang uses it. As someone who hasn't been able to use Erlang in his day job for a year now, I sorely miss the language.

In nearly every other language, when you call a function, the top of the function typically involves a fair bit of analysis of the arguments to decide what needs to be done.

(That's being generous: typically the entire body of the function revolves around making decisions about what to do, such that you don't know what's going to come out of the function until you've traversed multiple branch options.)

In well-written Erlang, the function itself branches at the top, taking advantage of pattern matching, destructuring, and function heads.

Let's say you're passing around arbitrary data in the form of a tuple that you need to display. Or not, depending on the value of some debug flag.

In Python you might see code like this, assuming that an integer is stored in your program like ('int', 3) and a string might have some arbitrary label, so it's ('str', 'label', 'real string'):

  if (debug):
    display(x)
  
  def display(x):
    if (x[0] == 'int'):
      display_int(x[1])
    elif (x[0] == 'str'):
      display_string(x[1], x[2])
  

In Erlang, you can branch and destructure at the function head. You don't check the debug flag in the calling code, just pass it along for the function to decide what to do with it; if the flag is false, the function just returns false. (Variables in Erlang are capitalized; the lower-case "strings" in this code are atoms, also called symbols in some languages.)

  display(_, false) ->
    false;
  display({int, N}, _) ->
    display_int(N);
  display({str, Label, String}, _) ->
    display_string(Label, String).

Since you can choose the key data elements in your function arguments and branch accordingly in the function head, it becomes immediately obvious looking at the code how many different ways the code can evaluate, and the destructuring in the function heads means you don't have to waste code chunking the data apart before working with it.

(Updated: forgot to include the debug flag in the 2nd and 3rd function heads. In all 3 heads, the _ pseudo-variable basically says "I don't care what value we have here". Another option would be to use _Debug in the 2nd and 3rd heads to indicate to the reader what the flag is, or use true since we're expecting that value.)

> "More frequently used operators should be less verbose" seems reasonable to me.

Syntax that looks pretty in isolation is a poor design guideline for programming language design. It ignores the problems of writing and debugging this code. I don't know how many bugs went unnoticed because of the "if (a = b)" mistake but it certainly weren't few. Sure, nowadays the compiler warns you about that but that took surprisingly long to be implemented.

The argument for saving a few keystrokes for potential longer debugging sessions is not a good argument. Code is much more often read than it is written.

But I didn't criticize Go's verbosity (after all, they "fixed" the assignment thin) but the mindset of doing or not doing things for specific reasons that look quite backwards for today (or let me be frank, just plain stupid) but the community then fights with vigorously for this. There are examples for that in the design of the language but the most egregious example of this is the package manager. This went from "we don't needs this" over "do it in this problematic way" over "let's do it like anybody else" to now "no, we are special, we need to do it completely differently".

IMO, Go would have been a fantastic language to have in the 90s. But looking at it from today's perspective, it looks outdated in many places. But compared to C which is a language of the 70s it is still great and therefore I understand its appeal for programmers who haven't found another language to replace C with (going from my own experience, most programmers have replaced C with multiple languages instead of just one).

I don't think that is a big issue. Just bind it to something else. In RStudio by default <- is bound to alt and -.

Shift key?

The Rebol family of languages works like that.

Self and Newspeak sort of do it this way, adding implicit self to Smalltalk's keyword syntax and accessor convention.

These 'accessors' also work on local variables, there is no special syntax for assignment. So when you write x it means send the message x, which starts its lookup in the local environment and works itself outwards. When you write x:2 it sends the message x: with argument 2, also starting in the local environment.

The accessors are automatically generated in pairs for slots. It sorta works, but it seems a bit too convoluted just to say "hey, we can do everything with just messaging".

It's not a perfect correspondence, but I think the point is simply to show that back in the 1950's, there was no consensus yet on how assignment ought to look.

It just happens that there was no consensus yet on how it should work, yet, either!

Then again, neither of the last 2 (modern) programming languages I've used have had FORTRAN/ALGOL-style assignment semantics, so I think the jury's still out.

Wait...LET was optional? Auigh! Whole months of my childhood, wasted!

  10 print "world"
  5 print "hello"
  20 goto 5

   018 LET P=P K * B -

   135 LET Q=1 F G / 1 - REC 0.00001 * - Q *

   016 FOR X=1 STEP 1 UNTIL T

Visual Basic, notably, made 'Let' optional, but made 'Set' mandatory when assigning object references.

I agree in that this doesn't really take conscious thought anymore. However, the article had the following:

> How can a = a + 1? That’s like saying 1 = 2.

It looks like a lot of us don't have (never had?) trouble accepting a statement like `a = a + 1` and, upon stepping back, thought maybe it had to do with our internal dialog (which is now probably intuition as we've been processing statements like this for so long).

Just get rid of the silly idea of allowing expressions as statements.

I don't think that's enough. Take the two following Python lines:

  a = b = c == d

  a = b == c == d

No expression is being used as a statement, yet you can't syntactically separate assignment from equality.

    a = b = (c == d)

    a = (b == c == d)

You're missing the point - languages like Pascal have a := assignment operator because the = operator is for comparison only. If you accidentally drop the :, then you have a simple Boolean expression. If this Boolean expression is used as a statement, by itself, then the result is a compiler error.

In math, "=" is an equivalence relation.

In C++17 not only can you do assignment in the conditional, you can declare new variables which have the scope of the then and else clauses.

But yes, most compilers will catch this case.

It's used often enough in loops like this:

    while (v = next()) { ... }

or, perhaps more usefully:

    while ((v = next()) != ERROR) { ... }

EDIT: just did a quick check, and LLVM did in fact warn me about this:

    if (x = 4) { ... }

To silence the error, you have to double up on the parenthesis, which I guess is a reasonable enough solution:

    if ((x = 4)) { ... }

You can catch this in c using -Wall.

Or simply enable compiler warnings for that...

Maybe lhs = rhs is the set of assignments implied by a postcondition. So x = 5 implies a single assignment, but x = ±5 could mean two possible assignments. Similarly, x ≠ 5 would mean all the possible assignments but x = 5.

Nope. Logical axioms are required logically, but not associated with time. Comprehension is associated with time, so I can understand how you might arrive where you did.

Equality doesn't exist in mathematics.

http://www.math.harvard.edu/~mazur/preprints/when_is_one.pdf

The punchline:

> In appropriate deference to the manifold ways an object can be presented to us, objects need only be given up to unique isomorphism, this being an enlightened view of what it means for one thing to be equal to some other thing.

In what way would 'source -> destination' not reflect the "actual" flow of data?

  destination -> source

thats the logically equivalent zoidberg operator

Using == and := would guarantee you never accidentally use = by itself (out of habit from other languages) because that's not a valid operator.

Prolog is a good example of a language where "=" doesn't mean assignment. In Prolog, "=" means unification: You can read X = Y (which is =(X, Y) in functional notation) as: "True iff X and Y are unifiable". You can think of unification as a generalization of pattern matching. For example, f(X, b) is unifiable with f(a, Y) by the substitution {X → a, Y → b}. I think this aspect would be a valuable addition to the article.

Fun fact: If (=)/2 were not available as a built-in predicate in Prolog, you could define it by a single fact:

    X = X.

Thus, you do not even need this predicate as a predefined part of the language.