5 ms·

I like everything Andreas did differently from Python, except the unusual normalization rules for variable names. This is crazy: VariableName == variable_

I like everything Andreas did differently from Python, except the unusual normalization rules for variable names. This is crazy: VariableName == variable_name == VaRiAbLe_NaMe

keypusher 11y ago
I brought it up recently in the #nim irc channel, trying to get a good explanation. The creator still seemed to think it was a good idea, and I could not convince him otherwise.
- scardine 11y ago
  Yeah, I feel your pain. This is a deal breaker for me. My OS of choice for the last 25 years has a case sensitive filesystem, all the programming languages I learned (well, except PHP) are case sensitive, it is too hard to unlearn. BTW, PHP has weird case sensitivity rules. Case sensitive (both user defined and PHP defined): * variables * constants * array keys * class properties * class constants Case insensitive (both user defined and PHP defined) * functions * class constructors * class methods * keywords and constructs (if, else, null, foreach, echo etc.)
  - dom96 11y ago
    Why would you need to unlearn it? Simply write code as you would write it in a case sensitive language.
    - scardine 11y ago
      I've been programming Python for a living for the last 8 years or so. In Python there is a convention for naming classes with `CamelCase` and instances with `snake_case`. I could do that in a case insensitive language, but I can't do this in Nim because it is not only case insensitive, it violates the "principle of least astonishment" by normalizing variable names in a way that makes `FooBar` equivalent to `foo_bar` or `F_o_O_b_A_r`. If you can't see the trouble with this, I rest my case.
      - dom96 11y ago
        If I understand you correctly, the convention is basically the following, right? class FooBar(): pass foo_bar = FooBar() The equivalent in Nim: type FooBar = object var foo_bar = FooBar() Compiles and runs perfectly fine. How can this be the case? Well, the identifier equality rules in Nim have changed a while back, to make the first letter of every identifier case sensitive. So, FooBar == Foo_Bar == Foobar, but fooBar != Foo_Bar.
        scardine 11y ago
        You are right. Nim is not case insensitive anymore, it is case sensitive for the first letter. But in my defense, the last time I checked it used to be! Quoting from the wayback machine: > Nimrod is a style-insensitive language. This means that it is not case-sensitive and even underscores are ignored: type is a reserved word, and so is TYPE or T_Y_P_E. The idea behind this is that this allows programmers to use their own preferred spelling style and libraries written by different programmers cannot use incompatible conventions.
      - klibertp 11y ago
        I can see potential problems, but have you actually tried it and found any problems in practice? And you can always just learn another naming convention. That's not hard. Almost every language comes with its own way of naming things. For me - I'm using really a lot of languages at the same time - it's actually helpful because it makes easier to tell which language I'm writing right now...
  - kevin_thibedeau 11y ago
    Case insensitive identifiers have no bearing on using case sensitive file names. Nim's system is admittedly baroque but it is an attempt to have (mostly) insensitivity without breaking the most common forms needed for C-interop. Just use it as if it were a fully insensitive language, choosing unique identifiers, and the partial case sensitivity will rarely be a problem.
- phaylon 11y ago
  Is there a way to enforce a particular style across a project? From what I've read the abiliity for projects to be internally consistent, even with third party library usage, seems to be one of the big advantages of this design-wise. So if you had an optional setting somewhere that enforces it, it might help communicate the intention of the feature.
- progman 11y ago
  There are actually good reasons to reject similar variable names in general. They are a no-go in scripting languages. Fortunately the Nim compiler catches typos. http://blog.codinghorror.com/the-case-for-case-insensitivity/ http://blog.codinghorror.com/the-case-for-case-insensitivity...
lmm 11y ago
Sounds sensible. Case sensitivity makes life harder for beginners and the advantages are minimal (would you really want to have two different variables called VariableName and variable_name in scope?). There are plenty of potential pitfalls (e.g. code that only compiles in Turkey), but the principle is a great idea.
- scardine 11y ago
  In Python there is a convention for naming classes with `CamelCase` and instances with `snake_case`. It works very well, you can always tell if you are dealing with a class or an instance. Personally I believe code is harder to read than to write, so I favor languages that are easier to read.
  - lmm 11y ago
    If such a convention applied consistently that would be great. But my Python experience is that it isn't, and an inconsistent convention is worse than useless. If such a distinction is to be meaningful then IMO the language itself needs to enforce it.
    - scardine 11y ago
      I agree, it should be mandatory - one of the things I like about Nim is static typing. Oddly enough, the "we are all consenting adults" attitude works in Python. Most patterns and interfaces are by convention instead of being enforced. People don't abuse Pythons permissive nature very often, and when they do they are frowned upon by the community. I think such deviations are easier to spot in Python compared to other languages, don't really know why.
    - piva00 11y ago
      Exactly why I like Go's conventions for public/private, when I was younger and less experienced I always thought that it was great to have freedom to name things however I wanted but now I can't find a good argument against opinionated and enforced conventions for naming. I actually would appreciate if someone could provide me one.
federico3 11y ago
Actually, VariableName != variable_name You can write ClassesLikePython and variables_like_python in Nim. Sometimes people end up having dangerously similar variable names in the same scope, e.g. username and user_name, where an incorrect tab-completion might introduce a bug. Nim would require the developer to choose better names.
- scardine 11y ago
  Two identifiers are considered equal if the following algorithm returns true: proc sameIdentifier(a, b: string): bool = a[0] == b[0] and a.replace(re"_|–", "").toLower == b.replace(re"_|–", "").toLower So, right, looks like it is case sensitive for the first character allowing the same convention from Python. Still, I find it dangerous: m_insensitive == min_sensitive
  - klibertp 11y ago
    This would be caught by the compiler. If you have m_insensitive declared in current scope you won't be able to define min_sensitive in this scope, the compiler would throw an error.

I like everything Andreas did differently from Python, except the unusual normalization rules for variable names. This is crazy: VariableName == variable_name == VaRiAbLe_NaMe

keypusher 11y ago

I brought it up recently in the #nim irc channel, trying to get a good explanation. The creator still seemed to think it was a good idea, and I could not convince him otherwise.

scardine 11y ago
Yeah, I feel your pain. This is a deal breaker for me. My OS of choice for the last 25 years has a case sensitive filesystem, all the programming languages I learned (well, except PHP) are case sensitive, it is too hard to unlearn. BTW, PHP has weird case sensitivity rules. Case sensitive (both user defined and PHP defined): * variables * constants * array keys * class properties * class constants Case insensitive (both user defined and PHP defined) * functions * class constructors * class methods * keywords and constructs (if, else, null, foreach, echo etc.)
- dom96 11y ago
  Why would you need to unlearn it? Simply write code as you would write it in a case sensitive language.
  - scardine 11y ago
    I've been programming Python for a living for the last 8 years or so. In Python there is a convention for naming classes with `CamelCase` and instances with `snake_case`. I could do that in a case insensitive language, but I can't do this in Nim because it is not only case insensitive, it violates the "principle of least astonishment" by normalizing variable names in a way that makes `FooBar` equivalent to `foo_bar` or `F_o_O_b_A_r`. If you can't see the trouble with this, I rest my case.
    - dom96 11y ago
      If I understand you correctly, the convention is basically the following, right? class FooBar(): pass foo_bar = FooBar() The equivalent in Nim: type FooBar = object var foo_bar = FooBar() Compiles and runs perfectly fine. How can this be the case? Well, the identifier equality rules in Nim have changed a while back, to make the first letter of every identifier case sensitive. So, FooBar == Foo_Bar == Foobar, but fooBar != Foo_Bar.
      - scardine 11y ago
        You are right. Nim is not case insensitive anymore, it is case sensitive for the first letter. But in my defense, the last time I checked it used to be! Quoting from the wayback machine: > Nimrod is a style-insensitive language. This means that it is not case-sensitive and even underscores are ignored: type is a reserved word, and so is TYPE or T_Y_P_E. The idea behind this is that this allows programmers to use their own preferred spelling style and libraries written by different programmers cannot use incompatible conventions.
    - klibertp 11y ago
      I can see potential problems, but have you actually tried it and found any problems in practice? And you can always just learn another naming convention. That's not hard. Almost every language comes with its own way of naming things. For me - I'm using really a lot of languages at the same time - it's actually helpful because it makes easier to tell which language I'm writing right now...
- kevin_thibedeau 11y ago
  Case insensitive identifiers have no bearing on using case sensitive file names. Nim's system is admittedly baroque but it is an attempt to have (mostly) insensitivity without breaking the most common forms needed for C-interop. Just use it as if it were a fully insensitive language, choosing unique identifiers, and the partial case sensitivity will rarely be a problem.
phaylon 11y ago
Is there a way to enforce a particular style across a project? From what I've read the abiliity for projects to be internally consistent, even with third party library usage, seems to be one of the big advantages of this design-wise. So if you had an optional setting somewhere that enforces it, it might help communicate the intention of the feature.
progman 11y ago
There are actually good reasons to reject similar variable names in general. They are a no-go in scripting languages. Fortunately the Nim compiler catches typos. http://blog.codinghorror.com/the-case-for-case-insensitivity/ http://blog.codinghorror.com/the-case-for-case-insensitivity...

lmm 11y ago

Sounds sensible. Case sensitivity makes life harder for beginners and the advantages are minimal (would you really want to have two different variables called VariableName and variable_name in scope?). There are plenty of potential pitfalls (e.g. code that only compiles in Turkey), but the principle is a great idea.

scardine 11y ago
In Python there is a convention for naming classes with `CamelCase` and instances with `snake_case`. It works very well, you can always tell if you are dealing with a class or an instance. Personally I believe code is harder to read than to write, so I favor languages that are easier to read.
- lmm 11y ago
  If such a convention applied consistently that would be great. But my Python experience is that it isn't, and an inconsistent convention is worse than useless. If such a distinction is to be meaningful then IMO the language itself needs to enforce it.
  - scardine 11y ago
    I agree, it should be mandatory - one of the things I like about Nim is static typing. Oddly enough, the "we are all consenting adults" attitude works in Python. Most patterns and interfaces are by convention instead of being enforced. People don't abuse Pythons permissive nature very often, and when they do they are frowned upon by the community. I think such deviations are easier to spot in Python compared to other languages, don't really know why.
  - piva00 11y ago
    Exactly why I like Go's conventions for public/private, when I was younger and less experienced I always thought that it was great to have freedom to name things however I wanted but now I can't find a good argument against opinionated and enforced conventions for naming. I actually would appreciate if someone could provide me one.

federico3 11y ago

Actually, VariableName != variable_name You can write ClassesLikePython and variables_like_python in Nim. Sometimes people end up having dangerously similar variable names in the same scope, e.g. username and user_name, where an incorrect tab-completion might introduce a bug. Nim would require the developer to choose better names.

scardine 11y ago
Two identifiers are considered equal if the following algorithm returns true: proc sameIdentifier(a, b: string): bool = a[0] == b[0] and a.replace(re"_|–", "").toLower == b.replace(re"_|–", "").toLower So, right, looks like it is case sensitive for the first character allowing the same convention from Python. Still, I find it dangerous: m_insensitive == min_sensitive
- klibertp 11y ago
  This would be caught by the compiler. If you have m_insensitive declared in current scope you won't be able to define min_sensitive in this scope, the compiler would throw an error.