5 ms·

I was hoping case sensitivity would be implemented but it seems like it was too controversial. I'm thinking at this point there might be too much resistance.

Symmetry 4y ago
I've come to increasingly accept it over time? I mean, I'd really like it if my_function() and myFunction() just weren't allowed in the same section of code but if you allow the user to have both it's probably better that they refer to the same function than different functions.
- tryptophan 4y ago
  It is a strange feature but it does have a good underlying idea. Why would having two functions, named makeFile and make_file in the same program ever be a good idea? Think of it as less of a language syntax feature and more of a code style enforcement paradigm. Good lsp support makes it mostly fine imo.
  - isofruit 4y ago
    Imo it goes beyond that. You have folks from Java etc. coming over with their camel-case as well as python folks with snake-case. Now despite both of them writing in their own styles, their code can interact, because when the java-programmer gives you a `validateObject` procedure from their package, the python developer can just use it as `validate_object`. Not being forced into other people's style choices is a really nice boon to me.
- thom 4y ago
  It's not so much that anybody thinks that mix is a good idea, but it's just what happens immediately in any C/C++ codebase if you're using any nontrivial combination of libraries at all. The feature is about providing consistency, not ignoring it.
- v3ss0n 4y ago
  My_function vs myFunction Is fine but do_me vs dome start to differ and do_me vs d_ome vs dom_e start to make things very much different. That's the real problem
  - xigoi 4y ago
    Rarely a problem. Why would you have two procedures named do_me and dome with the exact same signature?
    - int_19h 4y ago
      Because the other procedure does something with some dome?
      - xigoi 4y ago
        Then is should be named doSomethingWithDome.
matthiaswh 4y ago
It's apparent from the RFC discussion that there is no consensus on the topic. With little (proven) tangible benefit of making the change, and a large potential for backlash within the small existing community, I'm not certain it's worth the risk for Nim to make this move. https://github.com/nim-lang/RFCs/issues/456 https://github.com/nim-lang/RFCs/issues/456
- lostdog 4y ago
  Anyone who wants to use grep will just keep ignoring nim. Case insensitivity is pretty silly, and underscore insensitivy is just really silly. The way that modern languages force a single style is great, and it's a big strike against nim, which is an otherwise nice language.
  - throwaway_au_1 4y ago
    Ironically they reject tabs and require space indentation. Something something the complexity of supporting both. Yet we have style insensitivity..
    - isofruit 4y ago
      To be fair, you can tell your IDE to just turn tabs into spaces and call it a day, that's an issue for all of 5 minutes. What you can't do is tell your IDE to interpret camel-case as snake-case if you want (or vice versa), just because this package you really need uses camel-case and you want to use snake-case.
    - elcritch 4y ago
      That actually makes whitespace syntax in Nim much better. Can't recall the number of times I copied Python code snippets and had to track down lurking tabs.
      - int_19h 4y ago
        You can't mix tabs and spaces in the same file since Python 3, which completely solves this problem without imposing one or the other choice on the users.
throwaway_au_1 4y ago
I didn't know this existed. There's a lot I like about Nim, but total rejection of tab indentation, and now this style insensitivity thing, mean that for me personally, Nim will just stay an interesting language I see on HN from time to time.
- nikhilsimha 4y ago
  I am not a fan of case insensitivity either. But it must be easy to write a case insensitive grep. I wager that a nim grep would already exist. I do agree that this is a red flag decision.
  - michaelsbradley 4y ago
    https://nim-lang.org/docs/nimgrep.html https://nim-lang.org/docs/nimgrep.html If you use choosenim to install Nim several executables get built/downloaded along with the compiler: $ pwd && ls /Users/me/.nimble/bin choosenim nim nim-gdb nimble nimgrep nimpretty nimsuggest testament https://github.com/dom96/choosenim#readme https://github.com/dom96/choosenim#readme
- michaelsbradley 4y ago
  The partial case-insensitivity thing is not new, it's been part of Nim for a long time, maybe since its very beginning but I'm not sure about that. https://nim-lang.org/docs/manual.html#lexical-analysis-identifier-equality https://nim-lang.org/docs/manual.html#lexical-analysis-ident...
UxDnz0 4y ago
John Carmack has a take on it; https://twitter.com/ID_AA_Carmack/status/1592560938208710659?s=20&t=okwnHrPxZ2yPWKyTED5K7w https://twitter.com/ID_AA_Carmack/status/1592560938208710659...
- nicoburns 4y ago
  I think I agree with Carmack on this. I'm hyper aware of case now, but this was probably the major cause of errors for me when learning (didn't help that tooling was less good then, so there were no linters pointing out my errors).
  - derbOac 4y ago
    I guess for me it's one of those things I got tripped up on initially but came to appreciate later. It taught me how to be more precise about characters and reasoning about them in code. There's also cases where case sensitivity should matter in naming in my experience, and it's not possible without it.
    - UxDnz0 4y ago
      Personally this preciseness is just a distraction, but it sounds like you have learned from the constraints and can now take the training wheels off again. Very curious about those cases, yet to find one myself that was not because of a bad design decision. Though I am also very big on the idea of `ambiguous grammar, rigorous implementation`, for natural language too. (Toki Pona is a somewhat extreme example but the contextual grammar, and holistic minimalism is fascinating) Not to make it longer than needs to be; But take the example code in this readme: https://github.com/guzba/mummy https://github.com/guzba/mummy Being able to quickly script this without thinking about cases or style on the first pass is a really lovely way of reducing friction imho.
    - arc776 4y ago
      > There's also cases where case sensitivity should matter in naming in my experience, and it's not possible without it. I'm really curious, do you have any examples? I can't think of any that wouldn't be better served by using the type system.
aquova 4y ago
It's one of those things that, as a Nim hobbyist programmer, I think is a neat feature to have, but I could see being a big hesitation for use in professional environments.
- isofruit 4y ago
  Given that you tend to use linters in those environments as well and that you can turn it off anyway, I'd disagree on that one. There are other factors that would make me hesitate in a professional environment much more, such as community size and talentpool.
- xigoi 4y ago
  Why?
kindaAnIdiot 4y ago
The `--styleCheck:error` flag can be passed to make everything follow NEP1 style guide [0]. `--styleCheck:usages` can also be passed to instead make identifiers follow their original naming (Basically turning off style insensitivity) - [0]: https://nim-lang.org/docs/nep1.html https://nim-lang.org/docs/nep1.html
arc776 4y ago
Case sensitivity is worse in every way IMO. Look at Nim's implementation of UFCS, which means `foo(bar) == bar.foo`. This means only one possible `foo` that takes type of `bar` can be invoked. There's no ambiguity if `foo` is a method, a proc, or a field - if there were, you'd get a compile time error. Similarly, case insensitivity, of course, means `foo == fOO == fOo == foO`. Reducing these to one identifier means less ambiguity to the programmer and encourages either using sensible names that can't easily be confused, and/or unambiguous mechanisms like the type system designed for this purpose. Say you have a constant for 'light enabled' Instead of naming it `lEn`, it's better to use `type LightState = enum disabled, enabled` and write `light.set enabled` for so many reasons. Same goes for pretty much everything. It's worth noting as well that the language is very good at resolving overloads by type, so if you have your own object and create a `len` for it, it's not going to get confused with the string `len` or even a `lEn` constant. Even if you have a `lEn` and `len` that are used in the same context with the same types (why though), you can qualify it anyway with `module1.lEn` or `module2.len`. The language has so many easy tools to make things more explicit and easier to read at the same time. Ultimately, case sensitivity only really ends up encouraging bad naming practice without adding anything back.

Symmetry 4y ago

I've come to increasingly accept it over time? I mean, I'd really like it if my_function() and myFunction() just weren't allowed in the same section of code but if you allow the user to have both it's probably better that they refer to the same function than different functions.

tryptophan 4y ago
It is a strange feature but it does have a good underlying idea. Why would having two functions, named makeFile and make_file in the same program ever be a good idea? Think of it as less of a language syntax feature and more of a code style enforcement paradigm. Good lsp support makes it mostly fine imo.
- isofruit 4y ago
  Imo it goes beyond that. You have folks from Java etc. coming over with their camel-case as well as python folks with snake-case. Now despite both of them writing in their own styles, their code can interact, because when the java-programmer gives you a `validateObject` procedure from their package, the python developer can just use it as `validate_object`. Not being forced into other people's style choices is a really nice boon to me.
thom 4y ago
It's not so much that anybody thinks that mix is a good idea, but it's just what happens immediately in any C/C++ codebase if you're using any nontrivial combination of libraries at all. The feature is about providing consistency, not ignoring it.
v3ss0n 4y ago
My_function vs myFunction Is fine but do_me vs dome start to differ and do_me vs d_ome vs dom_e start to make things very much different. That's the real problem
- xigoi 4y ago
  Rarely a problem. Why would you have two procedures named do_me and dome with the exact same signature?
  - int_19h 4y ago
    Because the other procedure does something with some dome?
    - xigoi 4y ago
      Then is should be named doSomethingWithDome.

matthiaswh 4y ago

It's apparent from the RFC discussion that there is no consensus on the topic. With little (proven) tangible benefit of making the change, and a large potential for backlash within the small existing community, I'm not certain it's worth the risk for Nim to make this move. https://github.com/nim-lang/RFCs/issues/456 https://github.com/nim-lang/RFCs/issues/456

lostdog 4y ago
Anyone who wants to use grep will just keep ignoring nim. Case insensitivity is pretty silly, and underscore insensitivy is just really silly. The way that modern languages force a single style is great, and it's a big strike against nim, which is an otherwise nice language.
- throwaway_au_1 4y ago
  Ironically they reject tabs and require space indentation. Something something the complexity of supporting both. Yet we have style insensitivity..
  - isofruit 4y ago
    To be fair, you can tell your IDE to just turn tabs into spaces and call it a day, that's an issue for all of 5 minutes. What you can't do is tell your IDE to interpret camel-case as snake-case if you want (or vice versa), just because this package you really need uses camel-case and you want to use snake-case.
  - elcritch 4y ago
    That actually makes whitespace syntax in Nim much better. Can't recall the number of times I copied Python code snippets and had to track down lurking tabs.
    - int_19h 4y ago
      You can't mix tabs and spaces in the same file since Python 3, which completely solves this problem without imposing one or the other choice on the users.

throwaway_au_1 4y ago

I didn't know this existed. There's a lot I like about Nim, but total rejection of tab indentation, and now this style insensitivity thing, mean that for me personally, Nim will just stay an interesting language I see on HN from time to time.

nikhilsimha 4y ago
I am not a fan of case insensitivity either. But it must be easy to write a case insensitive grep. I wager that a nim grep would already exist. I do agree that this is a red flag decision.
- michaelsbradley 4y ago
  https://nim-lang.org/docs/nimgrep.html https://nim-lang.org/docs/nimgrep.html If you use choosenim to install Nim several executables get built/downloaded along with the compiler: $ pwd && ls /Users/me/.nimble/bin choosenim nim nim-gdb nimble nimgrep nimpretty nimsuggest testament https://github.com/dom96/choosenim#readme https://github.com/dom96/choosenim#readme
michaelsbradley 4y ago
The partial case-insensitivity thing is not new, it's been part of Nim for a long time, maybe since its very beginning but I'm not sure about that. https://nim-lang.org/docs/manual.html#lexical-analysis-identifier-equality https://nim-lang.org/docs/manual.html#lexical-analysis-ident...

UxDnz0 4y ago

John Carmack has a take on it; https://twitter.com/ID_AA_Carmack/status/1592560938208710659?s=20&t=okwnHrPxZ2yPWKyTED5K7w https://twitter.com/ID_AA_Carmack/status/1592560938208710659...

nicoburns 4y ago
I think I agree with Carmack on this. I'm hyper aware of case now, but this was probably the major cause of errors for me when learning (didn't help that tooling was less good then, so there were no linters pointing out my errors).
- derbOac 4y ago
  I guess for me it's one of those things I got tripped up on initially but came to appreciate later. It taught me how to be more precise about characters and reasoning about them in code. There's also cases where case sensitivity should matter in naming in my experience, and it's not possible without it.
  - UxDnz0 4y ago
    Personally this preciseness is just a distraction, but it sounds like you have learned from the constraints and can now take the training wheels off again. Very curious about those cases, yet to find one myself that was not because of a bad design decision. Though I am also very big on the idea of `ambiguous grammar, rigorous implementation`, for natural language too. (Toki Pona is a somewhat extreme example but the contextual grammar, and holistic minimalism is fascinating) Not to make it longer than needs to be; But take the example code in this readme: https://github.com/guzba/mummy https://github.com/guzba/mummy Being able to quickly script this without thinking about cases or style on the first pass is a really lovely way of reducing friction imho.
  - arc776 4y ago
    > There's also cases where case sensitivity should matter in naming in my experience, and it's not possible without it. I'm really curious, do you have any examples? I can't think of any that wouldn't be better served by using the type system.

aquova 4y ago

It's one of those things that, as a Nim hobbyist programmer, I think is a neat feature to have, but I could see being a big hesitation for use in professional environments.

isofruit 4y ago
Given that you tend to use linters in those environments as well and that you can turn it off anyway, I'd disagree on that one. There are other factors that would make me hesitate in a professional environment much more, such as community size and talentpool.
xigoi 4y ago
Why?

kindaAnIdiot 4y ago

The `--styleCheck:error` flag can be passed to make everything follow NEP1 style guide [0]. `--styleCheck:usages` can also be passed to instead make identifiers follow their original naming (Basically turning off style insensitivity) - [0]: https://nim-lang.org/docs/nep1.html https://nim-lang.org/docs/nep1.html

arc776 4y ago

Case sensitivity is worse in every way IMO. Look at Nim's implementation of UFCS, which means `foo(bar) == bar.foo`. This means only one possible `foo` that takes type of `bar` can be invoked. There's no ambiguity if `foo` is a method, a proc, or a field - if there were, you'd get a compile time error. Similarly, case insensitivity, of course, means `foo == fOO == fOo == foO`. Reducing these to one identifier means less ambiguity to the programmer and encourages either using sensible names that can't easily be confused, and/or unambiguous mechanisms like the type system designed for this purpose. Say you have a constant for 'light enabled' Instead of naming it `lEn`, it's better to use `type LightState = enum disabled, enabled` and write `light.set enabled` for so many reasons. Same goes for pretty much everything. It's worth noting as well that the language is very good at resolving overloads by type, so if you have your own object and create a `len` for it, it's not going to get confused with the string `len` or even a `lEn` constant. Even if you have a `lEn` and `len` that are used in the same context with the same types (why though), you can qualify it anyway with `module1.lEn` or `module2.len`. The language has so many easy tools to make things more explicit and easier to read at the same time. Ultimately, case sensitivity only really ends up encouraging bad naming practice without adding anything back.