6 ms·

There is a question of getting rid of style sensitivity in Nim 2: https://news.ycombinator.com/item?id=31238375 https://news.ycombinator.com/item?id=31238375

There is a question of getting rid of style sensitivity in Nim 2: https://news.ycombinator.com/item?id=31238375 https://news.ycombinator.com/item?id=31238375 This whole question generates a lot of controversy for some reason

cardanome 4y ago
People really care about weird stuff. There is trade offs to both sensitivity and insensitivity. Just because you are used to one approach from your favorite programming language does not mean the other way is "wrong". Want a consistent style? Use that nice --styleCheck:usages option. No problem at all. Honestly, I think Nim should keep the current approach just to filter out certain people.
- ezst 4y ago
  What are the arguments for insensitivity? I'm not used to it, and it seems to my rookie eyes that it only opens venues for confusion (forcing to pay closer attention to symbols to mentally "de duplicate" them), inconsistencies within a same/foreign code base that make joining a project/jumping into an external library just slightly harder, and more vim/emacs/tab/spaces jihads.
  - xigoi 4y ago
    The main advantage is that you can follow a consistent style in your codebase even if your dependencies follow a different style, so you don't have a situation like in Python where if you use the unittest module, you're forced into not following PEP8.
rich_sasha 4y ago
It actually is something that gives me pause for thought. In my field of coding (finance) ambiguity is terrifying and eventually you get it wrong. Maybe it's not so bad in practice, but looking from the outside, I think... really? To be specific, case-insensitivity doesn't bother me, but the automatic conversion from camel-case to snake-case... very much so.
- nimmer 4y ago
  Style insensitivity is a safety feature, not a problem. It prevents bugs where a developer mistakes one variable or proc for another having similar names. For example in another language you might have variables isReady, isready, is_ready and use the wrong one, leading to a bug. Nim does not allow defining 3 different variables like that.
  - rich_sasha 4y ago
    If it stopped at disallowing the similar names, I'd think it is quirky but fine. A little unusual but harmless, maybe even helpful as you say. But that I can, and other people's code can, refer to the same thing by different names, is a bridge too far. Like I say, it won't deter me from trying the language, probably (I've been saying it for a while), but certainly doesn't make me more keen to try it.
    - PMunch 4y ago
      The nice thing about being able to run others people code with your style is that your entire codebase stays in one consistent style. You don't run into issues like in other languages where one library author has done some dubious style choices which then propagates into your code. This was always a pain-point for me in Python. And I'm not certain what scenarios you envisage where this would be an issue, why do you care how other people call your functions?
      - rich_sasha 4y ago
        Dubious decisions in third-party libraries are common, but camel vs. snake case is probably not the main... I care about how a function is called because so much tooling around programming is effectively grep. I can grep for a function name and get a pretty good idea where it is called. There's also a million variants of grep - git grep, unholy regular expressions (recently I used one to find all instances where foo is called with exactly 2, not 3 params, in Python), IDE plugins and so on. GitHub search? Google search for exceptions? IIRC Nim comes with some kind of "nim-grep" that is camel-vs-snake-aware, but that doesn't fix all the other tools. The minor gripe, additionally, is that you often have quasi-singleton classes called "FooManager", then a single instance called "foo_manager". Now... are these colliding? Or not, because the first letter _is_ case-sensitive? What does "fooManager" map to then? In my utility function, this feature gives me nothing but concerns. But then again, I'm not (yet?) a user the Nim community provides for so... <meh>
christophilus 4y ago
It’s probably my biggest gripe with nim. I hope they drop it and provide a tool like gofmt to get everyone’s code into the same style.
- PMunch 4y ago
  Why though? With this feature you're able to import a library in a style you don't like and still be able to use it in whichever style you prefer.
- sausage_dog 4y ago
  Nim has a tool called nimpretty similar to gofmt
  - xigoi 4y ago
    As a frequent Nim user, I've tried it a few times and it doesn't seem to do much, other than reflow lines in not very logical places. I'd prefer an uncompromising formatter like Black/Prettier/StyLua.
- xigoi 4y ago
  gofmt doesn't seem to ensure consistency in naming styles.
Symmetry 4y ago
My ideal would be to simply not allow having my_variable and myVariable in the same namespace but given that you can do that in essentially every language I sort of prefer that they have to refer to the same thing.
- nimmer 4y ago
  This is exactly what Nim does. If you try to define both my_var and myVar it will error out. The benefit is to avoid confusing variables or procs named my_var, myVar and myvar.
  - Symmetry 4y ago
    If you define them both yes, but you're still free to use them both. var my_var = 1 myVar += 1 echo(my_var) Will happily compile and give you 2. I'd prefer an error in that case because while I'm not liable to make that mistake but I could easily mistype long_variable_name as long_variablename without noticing and then cause myself problems when I try to grep.
    - def- 4y ago
      nim --styleCheck:error c x This enforces the same capitalization style in your code: x.nim(1, 5) Error: 'my_var' should be: 'myVar'
    - nimmer 4y ago
      You can use --styleCheck:usages or a linter to ensure that the style is uniform. You cane enable styleCheck:usages by default in the compiler. Also, most editors do variable/proc autocompletion. Also you can use nimgrep if have to search across projects written by different people.
    - arc776 4y ago
      Searching has never been a problem for me in years of using Nim but there is `nimgrep` bundled for style insensitive search. Also I'm no RE wiz, but seems like RE might help if it came down it. Just to stress myself as an anecdote though, I have years in the language and it hasn't come up yet for me, and I've never needed to use `nimgrep`.

cardanome 4y ago

People really care about weird stuff. There is trade offs to both sensitivity and insensitivity. Just because you are used to one approach from your favorite programming language does not mean the other way is "wrong". Want a consistent style? Use that nice --styleCheck:usages option. No problem at all. Honestly, I think Nim should keep the current approach just to filter out certain people.

ezst 4y ago
What are the arguments for insensitivity? I'm not used to it, and it seems to my rookie eyes that it only opens venues for confusion (forcing to pay closer attention to symbols to mentally "de duplicate" them), inconsistencies within a same/foreign code base that make joining a project/jumping into an external library just slightly harder, and more vim/emacs/tab/spaces jihads.
- xigoi 4y ago
  The main advantage is that you can follow a consistent style in your codebase even if your dependencies follow a different style, so you don't have a situation like in Python where if you use the unittest module, you're forced into not following PEP8.

rich_sasha 4y ago

It actually is something that gives me pause for thought. In my field of coding (finance) ambiguity is terrifying and eventually you get it wrong. Maybe it's not so bad in practice, but looking from the outside, I think... really? To be specific, case-insensitivity doesn't bother me, but the automatic conversion from camel-case to snake-case... very much so.

nimmer 4y ago
Style insensitivity is a safety feature, not a problem. It prevents bugs where a developer mistakes one variable or proc for another having similar names. For example in another language you might have variables isReady, isready, is_ready and use the wrong one, leading to a bug. Nim does not allow defining 3 different variables like that.
- rich_sasha 4y ago
  If it stopped at disallowing the similar names, I'd think it is quirky but fine. A little unusual but harmless, maybe even helpful as you say. But that I can, and other people's code can, refer to the same thing by different names, is a bridge too far. Like I say, it won't deter me from trying the language, probably (I've been saying it for a while), but certainly doesn't make me more keen to try it.
  - PMunch 4y ago
    The nice thing about being able to run others people code with your style is that your entire codebase stays in one consistent style. You don't run into issues like in other languages where one library author has done some dubious style choices which then propagates into your code. This was always a pain-point for me in Python. And I'm not certain what scenarios you envisage where this would be an issue, why do you care how other people call your functions?
    - rich_sasha 4y ago
      Dubious decisions in third-party libraries are common, but camel vs. snake case is probably not the main... I care about how a function is called because so much tooling around programming is effectively grep. I can grep for a function name and get a pretty good idea where it is called. There's also a million variants of grep - git grep, unholy regular expressions (recently I used one to find all instances where foo is called with exactly 2, not 3 params, in Python), IDE plugins and so on. GitHub search? Google search for exceptions? IIRC Nim comes with some kind of "nim-grep" that is camel-vs-snake-aware, but that doesn't fix all the other tools. The minor gripe, additionally, is that you often have quasi-singleton classes called "FooManager", then a single instance called "foo_manager". Now... are these colliding? Or not, because the first letter _is_ case-sensitive? What does "fooManager" map to then? In my utility function, this feature gives me nothing but concerns. But then again, I'm not (yet?) a user the Nim community provides for so... <meh>

christophilus 4y ago

It’s probably my biggest gripe with nim. I hope they drop it and provide a tool like gofmt to get everyone’s code into the same style.

PMunch 4y ago
Why though? With this feature you're able to import a library in a style you don't like and still be able to use it in whichever style you prefer.
sausage_dog 4y ago
Nim has a tool called nimpretty similar to gofmt
- xigoi 4y ago
  As a frequent Nim user, I've tried it a few times and it doesn't seem to do much, other than reflow lines in not very logical places. I'd prefer an uncompromising formatter like Black/Prettier/StyLua.
xigoi 4y ago
gofmt doesn't seem to ensure consistency in naming styles.

Symmetry 4y ago

My ideal would be to simply not allow having my_variable and myVariable in the same namespace but given that you can do that in essentially every language I sort of prefer that they have to refer to the same thing.

nimmer 4y ago
This is exactly what Nim does. If you try to define both my_var and myVar it will error out. The benefit is to avoid confusing variables or procs named my_var, myVar and myvar.
- Symmetry 4y ago
  If you define them both yes, but you're still free to use them both. var my_var = 1 myVar += 1 echo(my_var) Will happily compile and give you 2. I'd prefer an error in that case because while I'm not liable to make that mistake but I could easily mistype long_variable_name as long_variablename without noticing and then cause myself problems when I try to grep.
  - def- 4y ago
    nim --styleCheck:error c x This enforces the same capitalization style in your code: x.nim(1, 5) Error: 'my_var' should be: 'myVar'
  - nimmer 4y ago
    You can use --styleCheck:usages or a linter to ensure that the style is uniform. You cane enable styleCheck:usages by default in the compiler. Also, most editors do variable/proc autocompletion. Also you can use nimgrep if have to search across projects written by different people.
  - arc776 4y ago
    Searching has never been a problem for me in years of using Nim but there is `nimgrep` bundled for style insensitive search. Also I'm no RE wiz, but seems like RE might help if it came down it. Just to stress myself as an anecdote though, I have years in the language and it hasn't come up yet for me, and I've never needed to use `nimgrep`.