Begin and end annoys me a bit too because it's harder to write. Yet, we learned years later that code is read more than written. Now, all the advice in the world is to optimize code for reading, maintenance, and extension. Kind of like what non-C languages were doing, eh? Short-hand could still be useful as we pick up little things like that easily without need for verbose syntax.
Now, := is another situation. Let me ask you: what did = mean before you learned programming? I'm guessing, as math teaches, it meant two things were equal. So, making = be the conditional check for equality is intuitive and reinforced by years. A colon is English for something similar where you assign one thing a more specific meaning. So, := for assignment and = makes sense even if a better syntax exists for := part. W
hat makes no sense is making the intuitive operator for equality (=) into assignment then equality becoming ==. We know it didn't make sense because Thompson did it when creating B from BCPL. His reason: personal preference. (sighs) At the worst, if I were him, I'd have done == for assignment and = for equality to capitalize on intuition.
It makes much more sense if you consider it from a logic perspective. '=' is material implication (→), and '==' is material biconditional (↔) - which is logically equivalent to (a → b) ∧ (b → a)... so two equal signs (the logical conjunction is redundant so you drop it). Computer science favors logic, so I'd be pretty surprised if it was simply personal preference.
I actually never considered that. That's a good idea. Now, hopefully I remember this if I see other Thompson papers. Use of formal logic in them or in his background might explain it.
To match math usage, a plain = should be when the programmer wants to state that two things are in fact equal. In debug builds, it would serve as an assertion. In release builds, it would be an optimization hint.
Contradicted yourself there. The equals is used in conditionals with other logical operators to assert equality is true or not. That's a legit use for it.
Hmm. That's interesting. It's closer to the other commenters definition. I like how they straight up call it "assume" for accuracy. :)
Note: This discussion on an "obvious" problem shows how deep the rabbit hole can go in our field in even the simplest thing. Kind of ridiculous and fun at same time haha.
Showing programming languages of different types to laypersons can be interesting experience. You can see just how intuitive or not on average something is. Most people I've shown code to knew begin was the start of an activity with end being the end of it. They were hit and miss on braces as they couldn't be sure what they signified.
In this case, though, it would be fine to use something smaller like braces, brackets, or parentheses. The reason is the intuition learns it quickly since the understanding is half there already: the braces visually wrap the statements. Not a big deal to me like equality was.
Now, := is another situation. Let me ask you: what did = mean before you learned programming? I'm guessing, as math teaches, it meant two things were equal. So, making = be the conditional check for equality is intuitive and reinforced by years. A colon is English for something similar where you assign one thing a more specific meaning. So, := for assignment and = makes sense even if a better syntax exists for := part. W
hat makes no sense is making the intuitive operator for equality (=) into assignment then equality becoming ==. We know it didn't make sense because Thompson did it when creating B from BCPL. His reason: personal preference. (sighs) At the worst, if I were him, I'd have done == for assignment and = for equality to capitalize on intuition.