16 ms·

Last time I was going to try it, I got sidetracked reading up on rules for identifier equality, prompted by noticing that the nim package bundled its own grep (

Last time I was going to try it, I got sidetracked reading up on rules for identifier equality, prompted by noticing that the nim package bundled its own grep (nimgrep). Basically, Nim ignores case (except for the first character) and underscores in identifier names, so the following is a valid Nim program and all those names refer to the same variable: var myVar = 1 my_var = 2 mYVAR = 3 echo(myVAR) Most people wouldn't actually write code like that, but I personally found it to be a turn-off. More on this: https://nim-lang.org/docs/manual.html#lexical-analysis-identifier-equality https://nim-lang.org/docs/manual.html#lexical-analysis-ident...

BoppreH 8y ago
I personally think it's a great idea. Much better than having a code base with mixed camelCase and snake_case because a library didn't follow the language convention. I've seen people write wrappers just to fix casing.
- joelthelion 8y ago
  A much better solution is to have a language-wide style guide, with a tool such as "go fmt" to enforce it.
  - alehander42 8y ago
    Interop with C/JS: you can't control all identifiers, because you can reuse a rich ecosystem of other language libs: you can't force their names to change EDIT: you can still change them in importc pragmas, but this still seems less nice to me. Still, you can reuse Nim libs even if they don't follow nep1: one can still use nimpretty/gofmt for his own codebase.
pelario 8y ago
Can somebody explain why would anyone consider this a good idea? I'm honestly puzzled.
- dymk 8y ago
  The goal was to make it so library authors could write Nim in their own "style" - some prefer snake_case, others prefer camelCase, maybe PascalCase. If you had your own preference one way or the other, you could call a library's `snake_case(foo)` function as `snakeCase(foo)` instead, and pretend that the library matched your own personal style. Of course, this isn't very useful in practice, and makes simple things like grepping for identifiers or Googling a function that much harder. Tools for refactoring also suffer. What's better is having a single style guide enforced by ordained tooling; e.g. PEP 8 for Python, Prettier for JavaScript, or gofmt for Go.
  - PMunch 8y ago
    In a perfect world, yes. But having worked with Python I must say not all Python libraries are PEP 8, and I've more than once ended up with a strange mix of styles. Nim on the other hand takes a different approach, don't trust anyone else to keep things the way you like it, but rather allow you to use it however you want. This means that if some inexperienced Nim programmer who didn't care to look at the NEP 1 style guide (yes Nim also has a style guide, which says Nim prefers camelCase), but nonetheless wrote an interesting library could still see his library used by others.
    - dom96 8y ago
      Something else to keep in mind is that Nim also has it's own version of gofmt in development, it's called nimpretty. If everyone is using this tool anyway then style insensitivity will not be a problem, and for those cases where some library uses snake_case instead the code formatter will still be able to format your code completely consistently even if you're using that library. There is no way that gofmt or any other language's code formatter can do that.
    - mikepurvis 8y ago
      Prior to Py3, not even the entire _standard library_ was PEP8: https://docs.python.org/2/library/queue.html https://docs.python.org/2/library/queue.html Before 2.6, the situation was even worse, with camel-case methods in the threading module: https://docs.python.org/2/library/threading.html https://docs.python.org/2/library/threading.html
narimiran 8y ago
> 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.
nimmer 8y ago
I've been using Nim for years and never ran into a collision between different variables due to style insensitivity. Using name completion in my editor is enough to keep the naming consistent. Try the language for a month before deciding. Also, the survey indicates that very few people are turned off by this feature: https://nim-lang.org/blog/2018/10/27/community-survey-results-2018.html https://nim-lang.org/blog/2018/10/27/community-survey-result...
- deleted 8y ago
  [deleted]
- h1d 8y ago
  Maybe because only enthusiasts are currently using it?
ziotom78 8y ago
OTOH, because of the same rule, the following abomination is legal in C++, but its analogous in Nim would trigger a compilation error: int main() { int myVar = 1; int my_var = 2; int mYVAR = 3; int myVAR = 4; // ... } I have seen a few codes in my life where complex routines with multiple nest levels had variables with names "x", "X", "_x", etc.
- nimmer 8y ago
  Yes, and not being able to have two different variables in the same code named "cryptotoken" and "crypto_token" is a feature. It saved me few bugs already.
citycide 8y ago
> Last time I was going to try it, I got sidetracked reading up on rules for identifier equality It's way too easy to ignore (or even embrace) the identifier equality rules in Nim to make this the hill you die on. My story's very similar to other responses - I've been using Nim for quite a while and these identifier rules have never been an issue. I strongly suggest anyone hung up on this monster under the bed try Nim anyway as it's really pleasant to use. It's sad that all Nim's benefits are sometimes drowned by mostly unfounded hangups on this identifier thing.
- aepiepaey 8y ago
  Considering how common it seems to be, it wouldn't be fair to call it "unfounded". Anyway, don't worry: I didn't die on that hill. I've had the opportunity to spend some more time on Nim since. There was a set amount of time available to spend on Nim at that point, and all that time went into finding out why nimgrep exists in the first place, then reading up on the background. It didn't help that all nimgrep's documentation had to say on the matter was "Nimgrep has particularly good support for Nim's eccentric style insensitivity", which doesn't really tell you anything unless you already know about Nim's style insensitivity.
mtinkerhess 8y ago
A lot of people are replying saying this isn't a big deal in practice. I believe them but I'll chime in and say this is also a dealbreaker for me. I would love to find a language for game / engine development that's as performant as C++ and as easy to use as C# or Python, but this issue scares me. If I search for a variable using any of my existing plain text search tools, I expect to find the variable. It makes me think that this isn't a language that's meant to be used by large teams on large, long-lived codebases.
- alehander42 8y ago
  You aren't supposed to use different styles in the same codebase: Nim is going to have a tool that can enforce this soon.
- dom96 8y ago
  > If I search for a variable using any of my existing plain text search tools, I expect to find the variable. I think you are over-estimating how inconsistent Nim code typically is. I have been coding in Nim for a very long time and I personally just use case insensitive search (which I use for all languages anyway). It's easy to tell from context what the identifier will be. If the code base is snake_case then I search for `foo_bar` if not then I search for `fooBar`. I cannot remember a single time this has failed me, and even if it does then the worst case is you'll need to search for the other alternative. There is really no trouble here and I feel like a lot of people, when they see this feature, worry too much because it's so different. Please please please reconsider, I know it's a strange feature and it doesn't feel worth it, but it really isn't a problem at all.
  - mtinkerhess 8y ago
    I totally hear you that this is not a huge inconvenience in practice. Part of me is worried that it becomes more and more of a problem the bigger the project gets. But mostly, it just seems like a really weird call to make for the language. There are real disadvantages to it -- I can't really rely on my search tools. So that... when you're using a library you can refer to its identifiers using a different capitalization convention if you want to--why is that important? I don't know, it just seems like a really weird call to make, and if that's one of the first things I've learned about the language it makes me think there are probably plenty of other weird things like it.

BoppreH 8y ago

I personally think it's a great idea. Much better than having a code base with mixed camelCase and snake_case because a library didn't follow the language convention. I've seen people write wrappers just to fix casing.

joelthelion 8y ago
A much better solution is to have a language-wide style guide, with a tool such as "go fmt" to enforce it.
- alehander42 8y ago
  Interop with C/JS: you can't control all identifiers, because you can reuse a rich ecosystem of other language libs: you can't force their names to change EDIT: you can still change them in importc pragmas, but this still seems less nice to me. Still, you can reuse Nim libs even if they don't follow nep1: one can still use nimpretty/gofmt for his own codebase.

pelario 8y ago

Can somebody explain why would anyone consider this a good idea? I'm honestly puzzled.

dymk 8y ago
The goal was to make it so library authors could write Nim in their own "style" - some prefer snake_case, others prefer camelCase, maybe PascalCase. If you had your own preference one way or the other, you could call a library's `snake_case(foo)` function as `snakeCase(foo)` instead, and pretend that the library matched your own personal style. Of course, this isn't very useful in practice, and makes simple things like grepping for identifiers or Googling a function that much harder. Tools for refactoring also suffer. What's better is having a single style guide enforced by ordained tooling; e.g. PEP 8 for Python, Prettier for JavaScript, or gofmt for Go.
- PMunch 8y ago
  In a perfect world, yes. But having worked with Python I must say not all Python libraries are PEP 8, and I've more than once ended up with a strange mix of styles. Nim on the other hand takes a different approach, don't trust anyone else to keep things the way you like it, but rather allow you to use it however you want. This means that if some inexperienced Nim programmer who didn't care to look at the NEP 1 style guide (yes Nim also has a style guide, which says Nim prefers camelCase), but nonetheless wrote an interesting library could still see his library used by others.
  - dom96 8y ago
    Something else to keep in mind is that Nim also has it's own version of gofmt in development, it's called nimpretty. If everyone is using this tool anyway then style insensitivity will not be a problem, and for those cases where some library uses snake_case instead the code formatter will still be able to format your code completely consistently even if you're using that library. There is no way that gofmt or any other language's code formatter can do that.
  - mikepurvis 8y ago
    Prior to Py3, not even the entire _standard library_ was PEP8: https://docs.python.org/2/library/queue.html https://docs.python.org/2/library/queue.html Before 2.6, the situation was even worse, with camel-case methods in the threading module: https://docs.python.org/2/library/threading.html https://docs.python.org/2/library/threading.html

narimiran 8y ago

> 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.

nimmer 8y ago

I've been using Nim for years and never ran into a collision between different variables due to style insensitivity. Using name completion in my editor is enough to keep the naming consistent. Try the language for a month before deciding. Also, the survey indicates that very few people are turned off by this feature: https://nim-lang.org/blog/2018/10/27/community-survey-results-2018.html https://nim-lang.org/blog/2018/10/27/community-survey-result...

deleted 8y ago
[deleted]
h1d 8y ago
Maybe because only enthusiasts are currently using it?

ziotom78 8y ago

OTOH, because of the same rule, the following abomination is legal in C++, but its analogous in Nim would trigger a compilation error: int main() { int myVar = 1; int my_var = 2; int mYVAR = 3; int myVAR = 4; // ... } I have seen a few codes in my life where complex routines with multiple nest levels had variables with names "x", "X", "_x", etc.

nimmer 8y ago
Yes, and not being able to have two different variables in the same code named "cryptotoken" and "crypto_token" is a feature. It saved me few bugs already.

citycide 8y ago

> Last time I was going to try it, I got sidetracked reading up on rules for identifier equality It's way too easy to ignore (or even embrace) the identifier equality rules in Nim to make this the hill you die on. My story's very similar to other responses - I've been using Nim for quite a while and these identifier rules have never been an issue. I strongly suggest anyone hung up on this monster under the bed try Nim anyway as it's really pleasant to use. It's sad that all Nim's benefits are sometimes drowned by mostly unfounded hangups on this identifier thing.

aepiepaey 8y ago
Considering how common it seems to be, it wouldn't be fair to call it "unfounded". Anyway, don't worry: I didn't die on that hill. I've had the opportunity to spend some more time on Nim since. There was a set amount of time available to spend on Nim at that point, and all that time went into finding out why nimgrep exists in the first place, then reading up on the background. It didn't help that all nimgrep's documentation had to say on the matter was "Nimgrep has particularly good support for Nim's eccentric style insensitivity", which doesn't really tell you anything unless you already know about Nim's style insensitivity.

mtinkerhess 8y ago

A lot of people are replying saying this isn't a big deal in practice. I believe them but I'll chime in and say this is also a dealbreaker for me. I would love to find a language for game / engine development that's as performant as C++ and as easy to use as C# or Python, but this issue scares me. If I search for a variable using any of my existing plain text search tools, I expect to find the variable. It makes me think that this isn't a language that's meant to be used by large teams on large, long-lived codebases.

alehander42 8y ago
You aren't supposed to use different styles in the same codebase: Nim is going to have a tool that can enforce this soon.
dom96 8y ago
> If I search for a variable using any of my existing plain text search tools, I expect to find the variable. I think you are over-estimating how inconsistent Nim code typically is. I have been coding in Nim for a very long time and I personally just use case insensitive search (which I use for all languages anyway). It's easy to tell from context what the identifier will be. If the code base is snake_case then I search for `foo_bar` if not then I search for `fooBar`. I cannot remember a single time this has failed me, and even if it does then the worst case is you'll need to search for the other alternative. There is really no trouble here and I feel like a lot of people, when they see this feature, worry too much because it's so different. Please please please reconsider, I know it's a strange feature and it doesn't feel worth it, but it really isn't a problem at all.
- mtinkerhess 8y ago
  I totally hear you that this is not a huge inconvenience in practice. Part of me is worried that it becomes more and more of a problem the bigger the project gets. But mostly, it just seems like a really weird call to make for the language. There are real disadvantages to it -- I can't really rely on my search tools. So that... when you're using a library you can refer to its identifiers using a different capitalization convention if you want to--why is that important? I don't know, it just seems like a really weird call to make, and if that's one of the first things I've learned about the language it makes me think there are probably plenty of other weird things like it.