3 ms·

The problem that nim have and many afraid to go nim is case and style insensitivity. Is_land == island == IsLaND == is-land It is bad in team setting, in real

by v3ss0n 2y ago

The problem that nim have and many afraid to go nim is case and style insensitivity. Is_land == island == IsLaND == is-land It is bad in team setting, in real world projects. How it goes now ? Last time I checked the main dev refuse to do anything about against popularity vote In Github. Otherwise awesome project and documentation Fusion Os

googh 2y ago
I think this problem can be solved using either a linter or formatter-like tool that makes naming consistent before the code gets committed.
- v3ss0n 2y ago
  Do we have proper linter for that now?
- archargelod 2y ago
  Nim compiler supports a style enforcing flag `--styleCheck`, that can display hints or error on compilation.
nurettin 2y ago
I've seen Delphi ERP projects worked on by dozens of people and case insensitivty of Pascal was never ever the issue. You choose something and stick to it. The concerns and fears are mostly due to inexperience.
- pjmlp 2y ago
  True, but in Delphi's case _ and - aren't part of case insensitivty, that is probably a bit too far.
- v3ss0n 2y ago
  And no such thing ever exist in other languages as first letter sensitive identifiers
Varriount 2y ago
I agree that it's unusual (and likely scares off some), however it's not entirely case insensitive. First, dashes/hyphens (`-`) can't be part of identifiers. Second, the first character of an identifier is not case insensitive. So: FooBar != fooBar FooBar == Foobar Most of the developers in the community are ambivalent about it, because it rarely ever causes problems. If you end up misspelling an identifier, you're nearly always going to get a compile-time error due to static typing anyway.
- IshKebab 2y ago
  Ha this always happens with case insensitivity. It's case insensitive.... except for some situations you need to now remember. I believe PHP has this issue too. It isn't a good look that they made the same mistakes as PHP.
  - otherme123 2y ago
    Nim has a good reason to do it: library interop. You can use a third party library that for some reason uses snake case, but you want to follow the camel case that NEP recomends. You just do it, and your codebase is all in the same style. In fact, it the third party library updates their case, it doesn't break Nim code that depends on it (that happened for example to Python Selenium, when they went from camelCase inherited from Java to snake_case recomended in PEP8, forcing all dependent code to update). I personally don't like that you can have "is_OK" and "isok" and "is_ok" in the same code as three valid different things. Or having "GL_FLOAT" and "GLFloat". Both options come with tradeoffs. Don't jump so quickly into "that is a mistake" and allow the devs the benefit of the doubt. There is only one rule you need to remember in Nim: only the first character case matters.
    - IshKebab 2y ago
      That's not a good reason. Why not just standardise the entire ecosystem on the same style? If you think that sounds infeasible, consider that Rust, Go and even Python have done this with no problem.
cardanome 2y ago
It is so that you can use external libraries with your preferred style without having to convert. It is a pretty amazing feature. Your problem is just imaginary. A consistent case style should always be enforced regardless if you have a case insensitive language or not. There is no real world case where you would want is_land and isLand to exists both in your code and be separate variables.
- v3ss0n 2y ago
  There are many code that have `class restController` in title cases and instance `restcontroller = RestController()` you can check around in the GitHub world. How it would effect? I haven't touched nim since that decision to keep those insensitivities.
  - cardanome 2y ago
    That should work fine since the first letter is still case sensitive in nim.
poulpy123 2y ago
While I don't like too, at the end it's just a detail. All languages have their issues
netbioserror 2y ago
Ends up being a total non-issue in the real world. I use it for a mission-critical CLI application called by a number of backend systems. I use snake_case for virtually everything save for object type names. There is no global scope and modules keep most symbols segregated. I have yet to have a symbol collision issue. I get to use foreign package symbols in my own style. On multi-dev projects I'd expect a style to be enforced, and given module segregation, a collision should be fairly simple to suss out. Especially if you use `from module import nil` and force module name qualification.

by v3ss0n 2y ago

googh 2y ago

I think this problem can be solved using either a linter or formatter-like tool that makes naming consistent before the code gets committed.

v3ss0n 2y ago
Do we have proper linter for that now?
archargelod 2y ago
Nim compiler supports a style enforcing flag `--styleCheck`, that can display hints or error on compilation.

nurettin 2y ago

I've seen Delphi ERP projects worked on by dozens of people and case insensitivty of Pascal was never ever the issue. You choose something and stick to it. The concerns and fears are mostly due to inexperience.

pjmlp 2y ago
True, but in Delphi's case _ and - aren't part of case insensitivty, that is probably a bit too far.
v3ss0n 2y ago
And no such thing ever exist in other languages as first letter sensitive identifiers

Varriount 2y ago

I agree that it's unusual (and likely scares off some), however it's not entirely case insensitive. First, dashes/hyphens (`-`) can't be part of identifiers. Second, the first character of an identifier is not case insensitive. So: FooBar != fooBar FooBar == Foobar Most of the developers in the community are ambivalent about it, because it rarely ever causes problems. If you end up misspelling an identifier, you're nearly always going to get a compile-time error due to static typing anyway.

IshKebab 2y ago
Ha this always happens with case insensitivity. It's case insensitive.... except for some situations you need to now remember. I believe PHP has this issue too. It isn't a good look that they made the same mistakes as PHP.
- otherme123 2y ago
  Nim has a good reason to do it: library interop. You can use a third party library that for some reason uses snake case, but you want to follow the camel case that NEP recomends. You just do it, and your codebase is all in the same style. In fact, it the third party library updates their case, it doesn't break Nim code that depends on it (that happened for example to Python Selenium, when they went from camelCase inherited from Java to snake_case recomended in PEP8, forcing all dependent code to update). I personally don't like that you can have "is_OK" and "isok" and "is_ok" in the same code as three valid different things. Or having "GL_FLOAT" and "GLFloat". Both options come with tradeoffs. Don't jump so quickly into "that is a mistake" and allow the devs the benefit of the doubt. There is only one rule you need to remember in Nim: only the first character case matters.
  - IshKebab 2y ago
    That's not a good reason. Why not just standardise the entire ecosystem on the same style? If you think that sounds infeasible, consider that Rust, Go and even Python have done this with no problem.

cardanome 2y ago

It is so that you can use external libraries with your preferred style without having to convert. It is a pretty amazing feature. Your problem is just imaginary. A consistent case style should always be enforced regardless if you have a case insensitive language or not. There is no real world case where you would want is_land and isLand to exists both in your code and be separate variables.

v3ss0n 2y ago
There are many code that have `class restController` in title cases and instance `restcontroller = RestController()` you can check around in the GitHub world. How it would effect? I haven't touched nim since that decision to keep those insensitivities.
- cardanome 2y ago
  That should work fine since the first letter is still case sensitive in nim.

poulpy123 2y ago

While I don't like too, at the end it's just a detail. All languages have their issues

netbioserror 2y ago

Ends up being a total non-issue in the real world. I use it for a mission-critical CLI application called by a number of backend systems. I use snake_case for virtually everything save for object type names. There is no global scope and modules keep most symbols segregated. I have yet to have a symbol collision issue. I get to use foreign package symbols in my own style. On multi-dev projects I'd expect a style to be enforced, and given module segregation, a collision should be fairly simple to suss out. Especially if you use `from module import nil` and force module name qualification.