Perhaps one of the most unique little features of nim is its case and underscore sensitivity. I must confess that when I first read about it I thought it was a terrible idea. I thought it would result in having very inconsistent use of symbols in your code base! However a little later I read a comment on Hacker News (I believe) that made me understand that it could in fact do the exact opposite! The comment was that by letting you change the case and the use of underscores when referring to symbols that you import from _external modules it would in fact be possible to make your _own codebase more consistent. That is, it would let you use a single case and underscore convention, ignoring the convention used on the external modules that you import.
I think this is an amazing insight, which let me better appreciate this little nim feature. However, after writing some nim code I still do not find any valid reason to be able to change the case or the underscores of symbols _within a single module. Is there something I´m missing? It seems to me that being able to change the case of a symbol within the same module, perhaps even within the same procedure, could only lead to more inconsistent code.
Thus I wonder, wouldn't it make sense to make it an error (or at least a warning) to refer to the same symbol using different case or underscores, within the _same module. That is, the first usage would select the case and underscores that you will need to use in that particular module.
Wouldn't that make more sense? Or perhaps this has already been discussed, in which case sorry for repeating this argument.
I actually agree with that particular argument. However, once you have written a symbol once, most editors will let you use autocomplete (from the words in the current file or buffer) to easily type that symbol with the same case and underscores.
As I said, I don't think that referring to the same symbol using different case or underscores _on the same file would ever be a good idea, while doing so in _different files would be because it would allow you to use the same convention in all your code.
So my suggestion is that nim should keep letting you use whichever case and underscores that you want, but force you to be consistent on each individual file.
"wouldn't it make sense to make it an error (or at least a warning) to refer to the same symbol using different case or underscores, within the _same module"
Compilers should give warnings when there is a risk of the code won't function as intended ... but if symbols with differing cases are always treated by the compiler as the same symbol, there's no such risk when they do differ. If you want to enforce style, that should be done with another tool designed for that purpose.
However, this discussion is moot because this feature of Nim is going away ... see http://forum.nim-lang.org/t/191
Jibal: Please note, that post is more than a year old. Those changes have since been made (Nim has partial case sensitivity, the first letter of an identifier is case sensitive)
Didlybom: This is more the domain of a linter. If you want, you could probably implement it in the compiler, and then it could be used in nimsuggest to lint files.
Yes, I thought I might be out of date; sorry. So the issues here are not moot after all. Here is the correct info:
http://nim-lang.org/manual.html#identifier-equality
I think this is very much a move in the wrong direction ... Nim still has the case-insensitivity and underscore-ignoring that it has been criticized for, but now is less consistent about it, and lacks the style-insensitivity that motivated the feature.
I'm actually glad that nim has kept this feature. After the initial shock it seems like a good idea. I am also very happy that CamelCase has not become mandatory (I very much prefer the Python style which encourages the use of all lowercase symbols with the occasional underscore through in).
However I am not convinced that allowing the use of different cases or underscores within _the same module would ever be a good idea. Is there a rationale for it? I don't think this is something that should be left as a linter check. I think it should not be allowed by the language (or at least be considered a warning) as I see no benefits to it.
I think it should not be allowed by the language (or at least be considered a warning) as I see no benefits to it.
That may well be, but from the compiler implementor's view that just another arbitrary rule the compiler has to check. And we rather fix bugs and improve the documentation than dreaming up rules to boss around the people who picked Nim for its freedoms.
It was a great idea when it really provided style insensitivity, but now that it doesn't, it's a negative.
For you. For others it's still a great thing that we don't have to spend our time banning foo_bar proc names from Nimble packages.
jibal, if you're struggling for the truth, you can claim that "Nim is no longer style-insensitive", but for real use you can easily replace "foo_bar vs. FooBar" with ""foo_bar vs. fooBar". People mostly have habits regarding PascalCase/camelCase vs. snake_case, and rarely PascalCase vs. snake_case. Furthermore, x_y and xY as different identifiers are rarely used in the same code (in languages that allow it), but using both x``and ``X as different is quite common, and "first letter sensitivity" allows to do it. Here's obviously more gained than lost.
"avoiding the weirdness and inconsistency" - Some people think that all that is not C, is weird, it's of course a matter of tastes, but if to take everything not habitual as "weird", then why to look for another languages? And I don't find the current identifier handling inconsistent.
> Yes, but what coding standard uses camelCase exclusively? PascalCase is always used at least for types.
I'm not sure what argument you're making here. The whole point is to allow camelCase and PascalCase distinction to avoid name conflicts between types and procedures without throwing away interchangeable snake_case in most areas. Slightly limiting the design doesn't negate all of it's benefits.
> rules that are widely considered "weird" and problematic because special tools or IDE plugins are required
Case insensitivety allows multiple style preferences within community libs to coexist without fighting over pointless symbol preferences. It means your code base can be more internally consistent, even if it depends on libs who don't practice the same religion you do.
The arguments against it (IDE & browser tools, hard on brain, etc) are easily addressed, so it's hard to say they objectively outweigh those benefits. IDE tools are needed in modern development workflows for reasons beyond just symbol tracing, so why design around the idea that they don't exist? Browser tools and documentation searching aren't hard to write, and in reality it isn't difficult to read others' code even if they use underscore where you do not.
Semi-case-sensitivity still retains the lion's share of that. Sure we have to follow others' first-letter standard, but most of the time we agree on that anyways (caps for types, lowers for procs/vars/etc). It's mostly the underscores we have strong bias towards.
Plus, I'm not convinced that "going with the flow" here would really increase popularity much. As soon as we have better IDE tools which handle jump-to and suggest people will see case-insensitivity's positive aspects (an IDE which normalized the suggest list, or even all source/docs identifiers, would be a perfect example).
Note that using different cases or underscores on separate files would still be allowed (and generate no error or warning)!
Maybe this belongs to a linter, if nim ever provides one, but given how controversial this nim feature is, maybe some of the haters would be appeased if the nim compiler incorporated this check itself?
[off topic] How do you guys include other people's messages in your replies?
didlybom: [off topic] How do you guys include other people's messages in your replies?
Generally, copy and paste. For what it's worth, I like that in that it discourages excessive quoting.
when porting code from case sensitive languages to nim, not detecting case conflicts may cause the ported code to be buggy. I thought about this particular problem when contemplating how hard would it be to port Python's telnetlib to nim.
This is exactly what doesn't work and how you cannot design a language. You actually have to try it and then you'd notice that we have a type system to catch bugs. Or maybe I'm wrong and your porting efforts are severly hindered by this feature, but then again, you need to try it and come up with hard data and real world examples where the feature did bite you.
when porting code from case sensitive languages to nim, not detecting case conflicts may cause the ported code to be buggy. I thought about this particular problem when contemplating how hard would it be to port Python's telnetlib to nim.
This is exactly what doesn't work and how you cannot design a language. You actually have to try it and then you'd notice that we have a type system to catch bugs. Or maybe I'm wrong and your porting efforts are severly hindered by this feature, but then again, you need to try it and come up with hard data and real world examples where the feature did bite you.
OK, that is a very fair and reasonable response. No wonder nim is such a well designed language :-)
The only thing I can say before actually trying as you say is that I feel this could be a problem from my C and C++ experience. I know "feeling" is not hard data so let me try to put it some other way: I've seen (and written) quite a bit of C and C++ code which uses ALLCAPS constants (with the occasional underscore) and "lowercase" or "camelCase" variables. It is not rare in my experience to use the same name for a constant and a variable (with the only difference being the casing and the underscores) where the constant is used to specify the initial value of the variable, or perhaps its maximum value or something like that. My guess is that nim may catch many of those errors but perhaps not all of them (since the types would match)?
Anyway, I should try it as you say. My worry is that nim is quickly approaching 1.0 (yay!) and this is not something that you can make more restrictive after the fact (but you could arguably make it less restrictive if it proves not being a problem and still be backwards compatible).
LeuGim: if you're struggling for the truth, you can claim that "Nim is no longer style-insensitive"
I quoted the reference manual, which says that "Historically, Nim was a style-insensitive language". It will no longer be possible to describe Nim as "style-insensitive", and it will be harder to characterize or justify Nim's identifier rules. (However, I acknowledge that applies to many language features and is not in itself a reason to make design decisions.)
LeuGim: People mostly have habits regarding PascalCase/camelCase vs. snake_case, and rarely PascalCase vs. snake_case.
I've already addressed this with examples like BigInteger ... the "habit" from both the Java (PascalCase/camelCase) and C# (PascalCase only) worlds are to capitalize type names.
LeuGim: both x and X as different is quite common, and "first letter sensitivity" allows to do it. Here's obviously more gained than lost.
I've already addressed this. I don't disagree that the first letter should be case-sensitive.
LeuGim: "avoiding the weirdness and inconsistency" - Some people think that all that is not C, is weird
Again, I am talking about the greater community's perception of, and ability to accept and adopt, Nim, which was one of the drivers of this change, at least early on. This was the reason to change the name from Nimrod, even though that was a perfectly fine name.
LeuGim: it's of course a matter of tastes, but if to take everything not habitual as "weird", then why to look for another languages?
First, "everything not habitual" is your strawman formulation. Second, there many many other reasons to prefer Nim over the alternatives than "taste".
I won't say more on this since I'm already just repeating what I've already said and it's a dead horse; the decision has been made. I sincerely hope that those who do find the rules "weird" (again, that's not me; I appreciate the innovation) and have arguments that "are easily addressed" will get past their resistance and that Nim will see wide adoption.