191–200 of 367 posts
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 "<-".
x: 2
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…
Earlier quoted context omitted.
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.
The math is pretty straightforward. I assume they aren't implementing all of the surrounding logic that makes crypto such a bear.
My first programming teacher insisted we call the single = sign the 'gets' operator. So int x = 10 int y = x would read in English as x gets 10, y gets x. Shortly after that class I took a break from any coding. When I went to another school I saw Softmore and Junior level programmers still struggling with this. I retained the habit of using 'gets'and never had a problem with this.
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.
I've been programming professionally for 25 years using mostly C inspired languages, and I will still regularly write "if(foo = bar)" on a daily basis and not notice until there's an error. It's easily the most common syntax error I write, followed closely by using commas in my for-loop as apparently it looks like a function to my fingers: "for(x=0, x<10, x++)"
There is a Ruby idiom[0] that I find quite useful (esp. combined with a linter such as Rubocop), leveraging optional parens as a marker of intentional assignment: # bad if v = array.grep(/foo/) do_something(v) # some code end # good if (v = array.grep(/foo/)) do_something(v) # some code end Caught a number of nasty bugs that way. [0]: https://github.com/bbatsov/ruby-style-guide#safe-assignment-...
Earlier quoted context omitted.
It should be noted that in mathematics equivalence and equality are not the same thing. Letting ~ represent an equivalence relation on a set X: Equivalence relations have specific properties: x ~ x holds for all x in X x ~ y => y ~ x for all x, y in X x ~ y /\ y ~ z => x ~ z, for all x, y, z in X However, they do not have to be equal , merely equivalent by whatever our relationship requires (though they may be equal)…
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.
Earlier quoted context omitted.
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.
I definitely agree that assignments should be statement level operations. I don't think case-folding identifiers is helpful. The language has decreed fooBar is the same as foobar, and that handles the error where you spelled the same idea two different ways, but it fails silently on the error where you spelled two different things a similar way. Worse, there are some people who are very sensitive to case and will be…
Conceptually, what is the difference between these two identifiers:
myObjectInstance
MyObjectInstance
?
And the key here is the reason for the difference: if it's a typo, then a case-insensitive language design will allow it and no-harm, no-foul. If it's not a typo, then who wants to work on a codebase littered with identifiers whose only difference is case ? :-)
Earlier quoted context omitted.
This works for initialization, but not for reassignment. Most notably, it is absurd for statements like x = x + 1. Meanwhile, such self-referential updates are very common in imperative programming, so anyone designing the language would come across this.
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…
Here, you would write x' = x + 1 to give the recurrence relation x[n+1] = x[n] + 1. Or, more generally x' = f(x) for x[n+1] = f(x[n]). The reason for this is because in mathematics x = x + 1 is absurd (ignoring modulo arithmetic).
"takes the value", "is equal" and "becomes equal to" are not saying the same things.
What matters is inside the parser for the language, and expressions (as in spoken or written words) between people about the language. Confusion abounds in the latter, but a well designed language doesn't have moments of confusion in the former case.
Some of the choices incur backtracking cost parsing the input. Some don't but incur more keyboard presses per unit of code expressed.