Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Does “=” Mean Assignment?

hillelwayne.com

Post reply on HN
Print view View original

131–140 of 367 posts

Re: Why Does “=” Mean Assignment?

#131

Post by dxhdr »

aprao wrote: post #118
rdtsc wrote: post #13

Another interesting way to think about it is as "match". That is try to match the stuff on the right with the stuff on the left. Take Erlang for example: 1> X = 1. 1 2> X = 2. ** exception error: no match of right hand side value 2 Notice variables are immutable (not just values themselves). Once X becomes 1, it can only match with 1 after that. You might think this is silly or annoying, why not just allow reassignme…

Elixir has borrowed the pattern matching approach from Erlang, but allows rebinds which makes code refactoring easier. 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.

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.

Re: Why Does “=” Mean Assignment?

#132

Post by ben509 »

nailer wrote: post #4

Because programming languages are typically designed for the tiny group of existing programmers than the much larger group of future programmers. The same reason unnecessary tokens exist, and 'drop' means delete in databases. It's entirely cultural.

>Because programming languages are typically designed for the tiny group of existing programmers...

So this is a dilemma I have while working on a new language. I'd like to go with `:=`, but `=` is absurdly popular, and I'm trying to keep the language as approachable as possible.

I don't think the clarity of `:=` is so compelling that it outweighs the `ew, why are there colons in there` reaction that I think most novice coders would have.

(Remove redundant commentary about database stuffs.)

Re: Why Does “=” Mean Assignment?

#133

Post by kolpa »

most of this article is covered in the Wikipedia page:

https://en.wikipedia.org/wiki/Relational_operator#Confusion_...

but Wikipedia says: "The reason for all this being unknown. [footnote] Although Dennis Ritchie has suggested that this may have had to do with "economy of typing" as updates of variables may be more frequent than comparisons in certain types of programs"

while the OP says: "As Thompson put it:

Since assignment is about twice as frequent as equality testing in typical programs, it’s appropriate that the operator be half as long."

Thompson and Ritchie designed C together.

Re: Why Does “=” Mean Assignment?

#134

Post by kps »

User23 wrote: post #5

Because K&R had terrible keyboards so they abbreviated everything as much as possible. Traditionally := was used for assignment, which makes sense since it is an asymmetric symbol for an asymmetric operation.

Granted they had some bad keyboards; there's a oft-reproduced photo of Thompson & Ritchie at Teletype 33s, but those had '63 ASCII, including ←.

Probably more important is that the Unix/C developers came from Multics, written in PL/I, which (following Fortran) used ‘=’ for assignment. And Fortran was still important; Unix had a Fortran compiler at least as far back as Second Edition, when C was being born. Kernighan & Plauger's Elements of Programming Style used Fortran and PL/I for its examples, and Software Tools used Ratfor. ‘=’ is simply what they were used to.

Re: Why Does “=” Mean Assignment?

#135

Post by ben509 »

dkrich wrote: post #108

I always liked DHH's take on these sorts of arguments (paraphrasing): who the hell cares? Once you know the purpose of the '=' how often do you make mistakes reading or writing code? 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 o…

> because at the end of the day, how often do you not know whether a particular variable is a string or an integer?

I'm refactoring some data-pasta to more clearly declare types because we just have dicts of lists of whatever, so often enough that a random reader chimed in after 20 minutes.

Re: Why Does “=” Mean Assignment?

#136

Post by wpietri »

> Ken Thompson [...] personally, aesthetically, wanted to minimize the number of characters in source code.

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

Re: Why Does “=” Mean Assignment?

#138

Post by sanderjd »

dkrich wrote: post #108

I always liked DHH's take on these sorts of arguments (paraphrasing): who the hell cares? Once you know the purpose of the '=' how often do you make mistakes reading or writing code? 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 o…

My issue with the larger teams vs. smaller teams argument is that the price of success is finding yourself with the wrong tools because successful projects usually grow large teams. The counterargument is that the price of choosing the right tools for a large team may be failure when those tools don't let you execute quickly enough. I don't really buy this trade-off. Maybe it is true for the specific language of Java for a small team (I'm not so sure it is) or Ruby for a large team (I have lived this and found it to be anecdotally true, so I do buy this one), but I don't believe you have to make this choice; I believe there can be languages that are productive for small teams while avoiding foot-guns for large teams.

Re: Why Does “=” Mean Assignment?

#139

Post by kccqzy »

blattimwind wrote: post #78
jghn wrote: post #10

Earlier quoted context omitted.

There’s also <-, most commonly seen in R but draws it’s heritage from the APL keyboard

Common in Pre-Python pseudo code and algorithms.

When I write pseudo code I still use <- for assignment (or a \leftarrow in LaTeX), despite being fluent in Python now. I guess old habits die hard.

Re: Why Does “=” Mean Assignment?

#140

Post by triska »

derefr wrote: post #127
rdtsc wrote: post #13

Another interesting way to think about it is as "match". That is try to match the stuff on the right with the stuff on the left. Take Erlang for example: 1> X = 1. 1 2> X = 2. ** exception error: no match of right hand side value 2 Notice variables are immutable (not just values themselves). Once X becomes 1, it can only match with 1 after that. You might think this is silly or annoying, why not just allow reassignme…

Also valid in Erlang: 2 = X. {ok, Y} = X = foo(). Oh, and here's a fun one: 1> {X, X} = {1, 1}. {1, 1}. 2> {Y, Y} = {1, 2}. ** exception error: no match of right hand side value {1,2} If you're wondering what the use of that is, here's an Erlang "drop all occurrences of an element X from a list" function. (Prerequisite knowledge for this: Erlang functions have several clause-heads; which one is executed on each call…

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.
Post reply on HN