211–220 of 367 posts
I think they are forgetting that a lot of languages take que's from old math textbooks where you would see function definitions written as "f(x) = nx + b" or "y = nx + b" and constant assignment with a "c = " notation. if you want to calculate the output of a function into a data table(which is what early computers were often doing) iterating a variable x over a f(x) = xn + b(with n and b being fixed constants) is ex…
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.
I really like this about pascal. We read it out loud as "becomes the same as", this being what was actually happening. I've carried the habit over to C despite the bare =, it helps me reason and seems to aid in preventing the =/== error.
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
I think they are forgetting that a lot of languages take que's from old math textbooks where you would see function definitions written as "f(x) = nx + b" or "y = nx + b" and constant assignment with a "c = " notation. if you want to calculate the output of a function into a data table(which is what early computers were often doing) iterating a variable x over a f(x) = xn + b(with n and b being fixed constants) is ex…
Earlier quoted context omitted.
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…
Yes, but again, the issue is whether most developers will be hindered or helped by case-sensitivity in a language. Based upon my experience, identifier case-sensitivity is simply making things harder than they need to be on the developer. 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 cas…
In Haskell, one is a variable, the other is a type, and that's enforced by the language. It's the same, albeit by convention, in Java. There are a lot of cases where you want to describe a type and a thing, so apple = new Apple() is pretty reasonable.
When I think of case-insensitive languages, I'm thinking of Basic, LISP, SQL, and those don't have a lot of type declarations.
And consider two counter-examples:
my_instance vs myinstance
things vs THINGS
Those are motivators to me for pushing this off to the linter: there are a lot of subjective judgements in what should and shouldn't be the same, and having the language keep its rules for identifiers as simple possible seems like a good separation of concerns.
My final concern is metaprogramming and interoperability. In SQL, for instance, there are bizarre rules to work around case-insensitive identifiers. If another system asks you for "myObjectInstance" and "MyObjectInstance", it has to know your case folding rules to know those two identifiers are the same.
> If it's not a typo, then who wants to work on a codebase littered with identifiers whose only difference is case ? :-)
Ever worked on a Python project that interacts with Javascript, so it's snake and camel case?
I generally agree, I'd just prefer a gofmt-style utility that would just automatically resolve those and tidy everything up. I completely agree that just chucking error messages is a poor answer.
Finally, here's a challenge, if identifiers are going to be folded by the compiler: what locale should be used? In particular, how do you handle I, İ, i and ı?
> 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 actually rationalized the '=' symbol in assignment into the following statement, "Let 'left hand side' be equal to 'right hand side'". Using this wording resolves some dissonance around its overloaded usage.
Ditto. Fun fact: various dialects of BASIC let you optionally put LET before your assignment statements. So the following are equivalent: X = 10 LET X = 10
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…
From a language, library, or framework I want to be in and out as fast as possibly. I want to have unambiguous usage that is easily discoverable. I want to avoid having to load a million things into my memory -- not least because I work with a huge pile of legacy code that all uses different technology. Rails is not the worst system I've ever used for this, but it's edging up there. Ruby, as a language, I don't mind at all, but the coding convention of people who primarily use Rails is something that I think can be improved dramatically.
Of course, IMHO ;-)