5 ms·

> I personally found it to be a turn-off. I feel like this is mentioned (by the people who just glance over Nim) every time there is some discussion about Nim,

> I personally found it to be a turn-off. I feel like this is mentioned (by the people who just glance over Nim) every time there is some discussion about Nim, and IMO it is blown way out of proportion. In my cca year and half of using Nim, I not even once had a problem with the style insensitivity. IMO, you (general you) shouldn't use `my_foo` and `myFoo` for different things, regardless if a language allows for it or not.

JoeAltmaier 8y ago
I had an operating system with a parameter of a scalar process id, which in our parlance was spelled pidTarget. The documentation folk 'corrected' it in the manual to pIdTarget, which would mean a pointer to a target id. Not hard to make up any number of examples where spacing or capitalization matter for good reason. They matter to humans; its just silly to make them not matter to the compiler.
- PMunch 8y ago
  This is a reasonable concern, but after having used Nim for a couple of years I have never run into this as an actual issue. The benefit of being able to keep your entire program in one casing style outweighs these concerns. For that is the purpose of this style insensitivity, to allow you to use a library using snake_case in a project using camelCase and the other way around. And after having used Python with mixed case libraries I must say it is a good solution. Now back to your concern of identifiers being read in different ways meaning different things. Once you know that this will be an issue you tend to think about it when naming your variables, and so it tends to not really be an issue. The thing is that once you get used to it you know that `pidTarget` and `pIdTarget` is the same thing, so you either relax you expectations, or you don't construct your names with this ambiguity. And besides, a "pointer to a target id" and a "scalar process id" probably don't share the same type, so the compiler should be catching that anyways if you ever used it wrong.
  - tcoff91 8y ago
    The big issue for me is it interferes with code search tools. I like being able to use ripgrep to find all uses of an identifier. That becomes hard with style insensitivity.
    - beagle3 8y ago
      well, yes, that's why nimgrep exists. grep -i solves the case issue, and grep/ripgrep probably _should_ have a feature to ignore _ ; in which case you will be able to use them - but until then, nimgrep will do that work.
      - tcoff91 8y ago
        It seems crazy to me that people are so annoyed that their libraries have different style that we have to have additional tooling to make code search simple for the end-user.
        dom96 8y ago
        You don't _need_ additional tooling. You can get by with just searching as normal, it's not as if people's code bases are filled with random conventions or random case variations...
        tcoff91 8y ago
        style insensitivity WILL lead to typos that don't get caught. Someone will change the casing somewhere. Therefore you must always search with style insensitivity in mind.
        nimmer 8y ago
        Most people use completion anyways and it prevents this problem. Also, you can lint the code.
        beagle3 8y ago
- mratsim 8y ago
  That's bad naming, if those had the same type, that would lead to subtle hard to track bug because a dev used one pid instead of pId.
  - JoeAltmaier 8y ago
    Not in any typed language. Its instantly called out as an error.
    - alehander42 8y ago
      But it's so hard to read: I admit a good IDE might help, but maybe it's not bad to prevent this on lang level.
    - mratsim 8y ago
      that's why I said if those had the same type ;)
- nickpsecurity 8y ago
  "Not hard to make up any number of examples where spacing or capitalization matter for good reason. They matter to humans; its just silly to make them not matter to the compiler." This one point is always worth considering when deciding on user-facing portions of technology.
weavie 8y ago
Common lisp also ignores case (sort of..it's a little bit more complicated). I've never found it to be a problem - apart from the compiler always uppercases my symbols when it reports to me, it feels a bit like being shouted at.
- weavie 8y ago
  Forgot to add.. in common lisp everything is kebab-cased which makes case a lot less significant. Not sure what happens in Nim?
  - mratsim 8y ago
    kebab-case? Is that even a thing?
    - mhd 8y ago
      Not as common, as it clashes with using '-' for subtraction, but as that's never been a problem for Lisp, it's quite common there. Perl6 went that way, too, despite having infix syntax. But hey, it's Perl, we're used to syntactical warts.
      - weavie 8y ago
        Ah.. I had wondered why it wasn't used in most other languages. Now, of course it seems obvious.
    - klibertp 8y ago
      Sure, Lisps allow many more characters in the identifiers, including all traditional operators (makes sense, since the "operators" are just functions and they had to be defined somehow in the first place...) You get functions named like add-message! create-response/text bytes->string/utf-8 and so on. Kebab case refers to identifiers with words separated with minus sign, like some-class-member-doing-something etc. Some infix languages borrowed this, like Dylan and LiveScript, among others.
rbonvall 8y ago
I have written code to traverse matrices in which I use indices `I` and `J` to iterate over submatrices and indices `i` and `j` to iterate over individual values in a submatrix. Upper/lower case add a new dimension to name things that are related but different. But is not a deal breaker for me. If the language doesn't let me I can use `ii` or `i2` or whatever.
- narimiran 8y ago
  > I have written code to traverse matrices in which I use indices `I` and `J` to iterate over submatrices and indices `i` and `j` to iterate over individual values in a submatrix. Please notice that the first letter in Nim is case-sensitive, so `I` != `i`, and you can continue use your conventions. And before some new comment starts bashing that, I think this is a must so you can differentiate your types, written in PascalCase, from your variables, written in camelCase.
anentropic 8y ago
yeah but if you do that and the language lets you get away with it... ugh I did not know this about Nim and does also seem quite a big turn off and a bit of a WTF decision I have never coded any Nim, just read about it though :)
- mclehman 8y ago
  I've never used Nim either (mostly C/Perl6/Clojure), but all I hear when this gets brought up is that I would finally be able to use a consistent style for all code I write, regardless of whether or not I personally implemented everything I'm using.
- anentropic 8y ago
  thinking more about it... I guess the intention is NOT to let you carelessly use Myvar, MyVar and myvar willy-nilly in your code, as I had first imagined I assume the intention is to PREVENT you from deliberately defining those names as different vars, which would be confusing So, on reflection, maybe it is not such a WTF
mictlan_ 8y ago
A better rule would be a unique definition of: - "myVar" - "myvar" - "my_var" - etc inside a scope, once you define the first.

JoeAltmaier 8y ago

I had an operating system with a parameter of a scalar process id, which in our parlance was spelled pidTarget. The documentation folk 'corrected' it in the manual to pIdTarget, which would mean a pointer to a target id. Not hard to make up any number of examples where spacing or capitalization matter for good reason. They matter to humans; its just silly to make them not matter to the compiler.

PMunch 8y ago
This is a reasonable concern, but after having used Nim for a couple of years I have never run into this as an actual issue. The benefit of being able to keep your entire program in one casing style outweighs these concerns. For that is the purpose of this style insensitivity, to allow you to use a library using snake_case in a project using camelCase and the other way around. And after having used Python with mixed case libraries I must say it is a good solution. Now back to your concern of identifiers being read in different ways meaning different things. Once you know that this will be an issue you tend to think about it when naming your variables, and so it tends to not really be an issue. The thing is that once you get used to it you know that `pidTarget` and `pIdTarget` is the same thing, so you either relax you expectations, or you don't construct your names with this ambiguity. And besides, a "pointer to a target id" and a "scalar process id" probably don't share the same type, so the compiler should be catching that anyways if you ever used it wrong.
- tcoff91 8y ago
  The big issue for me is it interferes with code search tools. I like being able to use ripgrep to find all uses of an identifier. That becomes hard with style insensitivity.
  - beagle3 8y ago
    well, yes, that's why nimgrep exists. grep -i solves the case issue, and grep/ripgrep probably _should_ have a feature to ignore _ ; in which case you will be able to use them - but until then, nimgrep will do that work.
    - tcoff91 8y ago
      It seems crazy to me that people are so annoyed that their libraries have different style that we have to have additional tooling to make code search simple for the end-user.
      - dom96 8y ago
        You don't _need_ additional tooling. You can get by with just searching as normal, it's not as if people's code bases are filled with random conventions or random case variations...
        tcoff91 8y ago
        style insensitivity WILL lead to typos that don't get caught. Someone will change the casing somewhere. Therefore you must always search with style insensitivity in mind.
        nimmer 8y ago
        Most people use completion anyways and it prevents this problem. Also, you can lint the code.
      - beagle3 8y ago
mratsim 8y ago
That's bad naming, if those had the same type, that would lead to subtle hard to track bug because a dev used one pid instead of pId.
- JoeAltmaier 8y ago
  Not in any typed language. Its instantly called out as an error.
  - alehander42 8y ago
    But it's so hard to read: I admit a good IDE might help, but maybe it's not bad to prevent this on lang level.
  - mratsim 8y ago
    that's why I said if those had the same type ;)
nickpsecurity 8y ago
"Not hard to make up any number of examples where spacing or capitalization matter for good reason. They matter to humans; its just silly to make them not matter to the compiler." This one point is always worth considering when deciding on user-facing portions of technology.

weavie 8y ago

Common lisp also ignores case (sort of..it's a little bit more complicated). I've never found it to be a problem - apart from the compiler always uppercases my symbols when it reports to me, it feels a bit like being shouted at.

weavie 8y ago
Forgot to add.. in common lisp everything is kebab-cased which makes case a lot less significant. Not sure what happens in Nim?
- mratsim 8y ago
  kebab-case? Is that even a thing?
  - mhd 8y ago
    Not as common, as it clashes with using '-' for subtraction, but as that's never been a problem for Lisp, it's quite common there. Perl6 went that way, too, despite having infix syntax. But hey, it's Perl, we're used to syntactical warts.
    - weavie 8y ago
      Ah.. I had wondered why it wasn't used in most other languages. Now, of course it seems obvious.
  - klibertp 8y ago
    Sure, Lisps allow many more characters in the identifiers, including all traditional operators (makes sense, since the "operators" are just functions and they had to be defined somehow in the first place...) You get functions named like add-message! create-response/text bytes->string/utf-8 and so on. Kebab case refers to identifiers with words separated with minus sign, like some-class-member-doing-something etc. Some infix languages borrowed this, like Dylan and LiveScript, among others.

rbonvall 8y ago

I have written code to traverse matrices in which I use indices `I` and `J` to iterate over submatrices and indices `i` and `j` to iterate over individual values in a submatrix. Upper/lower case add a new dimension to name things that are related but different. But is not a deal breaker for me. If the language doesn't let me I can use `ii` or `i2` or whatever.

narimiran 8y ago
> I have written code to traverse matrices in which I use indices `I` and `J` to iterate over submatrices and indices `i` and `j` to iterate over individual values in a submatrix. Please notice that the first letter in Nim is case-sensitive, so `I` != `i`, and you can continue use your conventions. And before some new comment starts bashing that, I think this is a must so you can differentiate your types, written in PascalCase, from your variables, written in camelCase.

anentropic 8y ago

yeah but if you do that and the language lets you get away with it... ugh I did not know this about Nim and does also seem quite a big turn off and a bit of a WTF decision I have never coded any Nim, just read about it though :)

mclehman 8y ago
I've never used Nim either (mostly C/Perl6/Clojure), but all I hear when this gets brought up is that I would finally be able to use a consistent style for all code I write, regardless of whether or not I personally implemented everything I'm using.
anentropic 8y ago
thinking more about it... I guess the intention is NOT to let you carelessly use Myvar, MyVar and myvar willy-nilly in your code, as I had first imagined I assume the intention is to PREVENT you from deliberately defining those names as different vars, which would be confusing So, on reflection, maybe it is not such a WTF

mictlan_ 8y ago

A better rule would be a unique definition of: - "myVar" - "myvar" - "my_var" - etc inside a scope, once you define the first.