Live data from Hacker News

Why Does “=” Mean Assignment?

hillelwayne.com

291–300 of 367 posts

Re: Why Does “=” Mean Assignment?

#291

In R, it is actually distinguished that way, example: a a + 1 -> a # also works, but REALLY bad practice But, so does a = a + 1 Granted, there are a bunch of R haters (especially from people with formal CS educations), I think this convention makes a lot of sense. While most will disagree about the ' In case you are wondering, the difference between foo(x = 'value') x is declared in the scope of the function, whereas…

`->` is a bad practice? I like to use it at the end of a long `%>%` pipe. Reading the whole thing feels a lot more natural.

It is bad practice because you are hiding the side effect.

Re: Why Does “=” Mean Assignment?

#292

In R, it is actually distinguished that way, example: a a + 1 -> a # also works, but REALLY bad practice But, so does a = a + 1 Granted, there are a bunch of R haters (especially from people with formal CS educations), I think this convention makes a lot of sense. While most will disagree about the ' In case you are wondering, the difference between foo(x = 'value') x is declared in the scope of the function, whereas…

> Granted, there are a bunch of R haters (especially from people with formal CS educations), I think this convention makes a lot of sense. To be clear, the assignment syntax is great, it's other things that are the target of R haters' hate! Like a high-level language without hash tables.

You can use environments for hash tables.

Re: Why Does “=” Mean Assignment?

#293
post #259

Earlier quoted context omitted.

I would definitely prefer ‘destination <- source’ as it reflects the actual flow of data.

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

I would be ok with that too!

I must have misinterpreted dboreham as suggesting

  destination -> source
Which is very confusing to me.

Re: Why Does “=” Mean Assignment?

#294
post #165
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.

The point is that ':=' evolved in Algol 68 to solve the ambiguity inherent in '='. C is simply from a less thoughtful and primitive language family and modern languages still seem to be copying C's horrible syntax. It's also probably why technical papers are written in Algol-like pseudocode using the '<-' symbol in LaTeX for assignment.

"
    let mutable x = 4   // x is equal to 4
    x 

Re: Why Does “=” Mean Assignment?

#296

Earlier quoted context omitted.

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.

I would write these as a = b = (c == d) and a = (b == c == d) respectively. And I think it would make sense to have a syntax rule that strictly enforces parentheses around truthy expressions used in such contexts.

Right, but then you're using the parentheses to distinguish the assignment from the comparison, it's not just a matter of not allowing expressions as statements.

Re: Why Does “=” Mean Assignment?

#297

Earlier quoted context omitted.

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.

I think GP might have meant that to go the other way around, i.e. don't allow statements to also be expressions, and more specifically, make assignment a statement.

No, Python assignments are not expressions. "a = b = c" is just an assignment statement with multiple parts, it's not equivalent to "a = (b = c)", which in fact will throw a SyntaxError.

Re: Why Does “=” Mean Assignment?

#298
post #174

Earlier quoted context omitted.

I've heard the same but with 'becomes' rather than 'gets'. I think becomes works better for people with a mathematical background, where the concept of variables is totally natural. For people without this, 'gets' might be better because it helps anthropomorphize the variable. The coder 'gives' X a value to hold.

If you're speed reading some code 'becomes' is a bit of mouthful.

Do you mouth the name of operators when you read code? Like most people I do make the words sound in my head when reading text but only the variable names make sounds when reading code.

Re: Why Does “=” Mean Assignment?

#299
post #237

Earlier quoted context omitted.

I never liked the 'gets': "x gets 7" is fine but "x becomes the same as y" seems better than "x gets y"

that's wrong, though. x becomes a copy of y, which is only transiently the same.

Depends on the language, and the types of x and y. See e.g. python.

Re: Why Does “=” Mean Assignment?

#300
I value clarity and explicity a lot. And I’m someone who generally lines to think about proper naming of a variable twice to make it easier for future readers of code.

At the same time when reading

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

I think: Well, depends how you interpret it.

If the translation is „we state, that from now on, a is the previous value of a plus 1“ it’s totally ok.

Not a big difference from saying

a = b + c

So i‘m not sure if the usefulness if changing all languages to using := is that high that it’s worth to think about changing it in current languages - and even when inventing a new language I’m not sure if it’s helpful.

I also wonder if reassignment, beside counters that need to be changed with iteration/ appearance of the event to be counted, is a thing that should generally be avoided if possible. Ok maybe in general everything where data is transformed in iterations...

Post reply on HN