6 ms·

This feature makes very little sense to me. What's the justification for this?

by aikah 12y ago

progman 12y ago
Developer convenience. Some people like Hungarian notation, some like underscores. I consider it quite convenient as well. Probably there is a need for a tool for source code normalization so that everyone can choose his favorite notation in the whole Nim ecosystem.
- duaneb 12y ago
  I wouldn't consider the loss of identifier recognition a "convenience". This would be a major concern for my adopting the language. You also have to read others' code, as well...
federico3 12y ago
Safety! Having "my_cat" and "myCat" as different variables in the same space sometimes ends up with using the wrong variable, especially when using tab completion. The feature is not meant to encourage developers to use "my_cat" and "myCat" randomly within the same file.
- msie 12y ago
  I don't like the idea of a language encouraging sloppy coding.
  - federico3 12y ago
    This is not different than having foo_bar and foo_Bar as two different variables.
    - dragonwriter 12y ago
      Well, yes, it is. And its worse, especially when the variables aren't "foo_bar" and "foo_Bar", but, say, "cycle_often" and "cycle_of_ten".
      - progman 12y ago
        > "cycle_often" and "cycle_of_ten". Such an error is caught by the compiler. const cycle_often = 10 var cycle_of_ten : float ambig.nim:2:5: Error: redefinition of 'cycle_of_ten'
- krupan 12y ago
  "The feature is not meant to encourage developers to use 'my_cat' and 'myCat' randomly within the same file." I'm sure it's not, but it isn't doing a thing to discourage that. We stopped using case insensitive file systems a long time ago, didn't we?
  - federico3 12y ago
    ...actually we didn't.
  - dragonwriter 12y ago
    > We stopped using case insensitive file systems a long time ago, didn't we? Windows didn't. But even Windows doesn't use an underscore-insensitive file system.
- dkersten 12y ago
  I'd rather have them be different identifiers but with a compiler warning if they're found in the same file.
- dragonwriter 12y ago
  Safety might prohibit different identifiers with a certain degree of similarity, but it wouldn't treat different-but-similar identifiers as if they were the same. Treating them as the same creates more danger -- the danger that the programmer intended them to be different, but the language treated them the same -- rather than mitigating danger.
- rat87 12y ago
  Sometimes the best name for a variable is a variation of the associated class/function name.
rbehrends 12y ago
For example: http://blog.codinghorror.com/the-case-for-case-insensitivity/ http://blog.codinghorror.com/the-case-for-case-insensitivity...
- iopq 12y ago
  This doesn't make any sense. When I make a mistake in case, Rust just doesn't let me compile.
  - rbehrends 12y ago
    You get this problem when you have two identifiers (variables, functions, constants, etc.) that differ only in case and have the same type signature. Depending on whether you use one or the other form, you may get completely different behavior.
    - iopq 12y ago
      The convention is that upper case is types, lower case is variables. So you'd have to try hard to make that mistake.
      - rbehrends 12y ago
        That has nothing to do with types vs. variables. Try having a variable signon and a variable signOn. Or two functions with the same type signature, one called signon() and one signOn() (for example, imported from two different modules).
        kibwen 12y ago
        By default, the Rust compiler warns you when you use uppercase characters in variable and function identifiers. The community overwhelmingly adheres to this style. Rust is also extremely strongly-typed, so not only would you have to be willfully disabling the style warnings, you would have to have to manage to give them the same types, and furthermore given the nature of Rust code it's rather possible that you'll still get a compilation error due to using a variable in a way that it didn't expect. You also can't "accidentally" introduce new variables in Rust, as you can in Python via typos.

This feature makes very little sense to me. What's the justification for this?

by aikah 12y ago

This feature makes very little sense to me. What's the justification for this?

Developer convenience. Some people like Hungarian notation, some like underscores. I consider it quite convenient as well. Probably there is a need for a tool for source code normalization so that everyone can choose his favorite notation in the whole Nim ecosystem.

duaneb 12y ago
I wouldn't consider the loss of identifier recognition a "convenience". This would be a major concern for my adopting the language. You also have to read others' code, as well...

federico3 12y ago

Safety! Having "my_cat" and "myCat" as different variables in the same space sometimes ends up with using the wrong variable, especially when using tab completion. The feature is not meant to encourage developers to use "my_cat" and "myCat" randomly within the same file.

msie 12y ago
I don't like the idea of a language encouraging sloppy coding.
- federico3 12y ago
  This is not different than having foo_bar and foo_Bar as two different variables.
  - dragonwriter 12y ago
    Well, yes, it is. And its worse, especially when the variables aren't "foo_bar" and "foo_Bar", but, say, "cycle_often" and "cycle_of_ten".
    - progman 12y ago
      > "cycle_often" and "cycle_of_ten". Such an error is caught by the compiler. const cycle_often = 10 var cycle_of_ten : float ambig.nim:2:5: Error: redefinition of 'cycle_of_ten'
krupan 12y ago
"The feature is not meant to encourage developers to use 'my_cat' and 'myCat' randomly within the same file." I'm sure it's not, but it isn't doing a thing to discourage that. We stopped using case insensitive file systems a long time ago, didn't we?
- federico3 12y ago
  ...actually we didn't.
- dragonwriter 12y ago
  > We stopped using case insensitive file systems a long time ago, didn't we? Windows didn't. But even Windows doesn't use an underscore-insensitive file system.
dkersten 12y ago
I'd rather have them be different identifiers but with a compiler warning if they're found in the same file.
dragonwriter 12y ago
Safety might prohibit different identifiers with a certain degree of similarity, but it wouldn't treat different-but-similar identifiers as if they were the same. Treating them as the same creates more danger -- the danger that the programmer intended them to be different, but the language treated them the same -- rather than mitigating danger.
rat87 12y ago
Sometimes the best name for a variable is a variation of the associated class/function name.

rbehrends 12y ago

For example: http://blog.codinghorror.com/the-case-for-case-insensitivity/ http://blog.codinghorror.com/the-case-for-case-insensitivity...

iopq 12y ago
This doesn't make any sense. When I make a mistake in case, Rust just doesn't let me compile.
- rbehrends 12y ago
  You get this problem when you have two identifiers (variables, functions, constants, etc.) that differ only in case and have the same type signature. Depending on whether you use one or the other form, you may get completely different behavior.
  - iopq 12y ago
    The convention is that upper case is types, lower case is variables. So you'd have to try hard to make that mistake.
    - rbehrends 12y ago
      That has nothing to do with types vs. variables. Try having a variable signon and a variable signOn. Or two functions with the same type signature, one called signon() and one signOn() (for example, imported from two different modules).
      - kibwen 12y ago
        By default, the Rust compiler warns you when you use uppercase characters in variable and function identifiers. The community overwhelmingly adheres to this style. Rust is also extremely strongly-typed, so not only would you have to be willfully disabling the style warnings, you would have to have to manage to give them the same types, and furthermore given the nature of Rust code it's rather possible that you'll still get a compilation error due to using a variable in a way that it didn't expect. You also can't "accidentally" introduce new variables in Rust, as you can in Python via typos.