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

271–280 of 367 posts

Re: Why Does “=” Mean Assignment?

#271

Post by nailer »

dragonwriter wrote: post #111
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.

> 'drop' means delete in databases DROP doesn't mean DELETE. DROP object-type > object-name > is sort of like a macro for, loosely DELETE FROM catalog-relvar-for-object-type > WHERE name = object-name > Except that real RDBMSs don't usually have DDL that is really equivalent to DML against system tables, and particularly (esp historically, but still in many years DBs), DDL has a different relation to transaction proc…

It does according to your next sentence.

Re: Why Does “=” Mean Assignment?

#272

Post by nailer »

ben509 wrote: post #132
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 nov…

Why not 'is'?

Re: Why Does “=” Mean Assignment?

#273

Post by mpweiher »

jcranberry wrote: post #232
vlasev wrote: post #173

Earlier quoted context omitted.

You have something similar in mathematics. Recurrence relations. Since we are dealing with a sort of time difference inside a computer, something like "x = x + 1" can be interpreted as "the value of x at the next time unit is the value of x at the previous time unit plus one". That is "x[n+1] = x[n] + 1" and this is a recurrence relation. My guess is that early programmers were deeply aware of this time difference, s…

What you have there is a sequence. Recursively defined or not, taking the indices out of a sequence takes away the only thing that makes it a sequence (the mapping from the natural numbers) and would be a horrible abuse of notation. I think language designers were certainly consciously aware that they were designing something well defined, and chose to use this kind of syntax because its simpler, rather than an impli…

> What you have there is a sequence.

See Lucid[1]

>takes away the only thing that makes it a sequence

Unless everything is a sequence[1]

[1] http://www.cse.unsw.edu.au/~plaice/archive/WWW/1985/B-AP85-L...

Re: Why Does “=” Mean Assignment?

#274

Post by boomlinde »

icebraining wrote: post #167
nfoz wrote: post #42

Earlier quoted context omitted.

Yeah I was pretty surprised when I found out that assignment and equality can be totally syntactically separate and nonambiguous with miminal language-design effort. Just get rid of the silly idea of allowing expressions as statements. 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.

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.

Re: Why Does “=” Mean Assignment?

#275

Post by mpweiher »

roselan wrote: post #191
abakus wrote: post #15

The length of symbols should roughly be negatively correlated with its frequency. Since in procedural language, assignment is a much more common operation than equality check, it is reasonable to favor "=" over ":=" or even "<-".

What does prevent : to become the assignment operator of a language? It's short, and quite "explicit". x: 2

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".

Re: Why Does “=” Mean Assignment?

#276

Post by Sholmesy »

macintux wrote: post #69
Artemix wrote: post #57

Earlier quoted context omitted.

I'd also want to see the link, if available!

This is from a few years ago, my first time giving it, and I've never had the courage to actually watch it, so ymmv. https://youtu.be/E18shi1qIHU

Dude, this was great. Been looking to get into Erlang, but the "unfamiliarity" always shunned me away. Really nice talk.

Re: Why Does “=” Mean Assignment?

#279

Post by nfoz »

boomlinde wrote: post #274
icebraining wrote: post #167

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.

Well first I was super intriguied by the example.

But I agree with your conclusion, that statements should not also be expressions, so a = b = c shouldn't work (at least not the way we're used to, that the b = c is an assignment "statement" that also produces an expression value).

But in the end all this does is allow "a = b = c" to be a nonambiguous statement meaning, in more familiar notation, "a = b == c". Not exactly clear! So even though a language could use the same symbol for both assignment and equality-check, I don't recommend it! Although I still like to keep statements and expressions as strictly non-interchangeable constructs.

Re: Why Does “=” Mean Assignment?

#280

Post by bhaak »

mikekchar wrote: post #218
bhaak wrote: post #14

> Since assignment is about twice as frequent as equality testing in typical programs, it’s appropriate that the operator be half as long. 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.

I'm not sure what you find disquieting about the idea. "More frequently used operators should be less verbose" seems reasonable to me. What I find a bit strange about Go is that if they have that mindset then it's still a fairly verbose language, syntactically -- at least compared to some other modern languages. It seems to hang on to the familiarity of C syntax with a few optimisations. Which, of course, is not nece…

> "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).

Post reply on HN