8 ms·

Can't get past the style insensitivity thing. Seems like a ridiculous 'feature' to build into a lang.

kwhitefoot 4y ago
I think the opposite. Case sensitivity beyond the first character just makes life difficult.
geenat 4y ago
It's a big plus for library and FFI interop so external styles don't take over your entire project. Also, John Carmack: https://mobile.twitter.com/id_aa_carmack/status/1592560938208710659 https://mobile.twitter.com/id_aa_carmack/status/159256093820...
- IshKebab 4y ago
  Plenty of programming languages have "did you mean xxx?" in error messages. Plus using IDEs means you will mostly autocomplete identifiers anyway. I don't buy it.
  - otherme123 4y ago
    The point is to use third party libraries while keeping your prefered case in your code. You prefer your code in CamelCase, but some other guy made a library in snake_case. Still you can use the library using CamelCase, and not mixing. E.g. The Python Selenium library used to be in CamelCase, while almost all code in Python is snake_case. By using Selenium you ended up with code like: my_button = browser.getElementById("Button") They rewrote the whole library to be in snake_case, a change that forced a lot of code rewrite downstream. Even the Python builtin library has case inconsistencies (logging module is camelCase, sys has both alllowercase and snake_case) that weren't fixed even in 2to3. Nim would have handle this efortlessly, allowing you to use get_element_by_id or getElementById in the old library, and avoiding you the effort to rewrite your code if the Selenium mantainers decided for a case change. You can refactor your case without fear of making life worse for your users.
    - gjm11 4y ago
      An alternative design would be: when you bring in an external library, there's a mechanism to rename the symbols in it. The downside is that for each library you want to do this to, _once_ you have to spend a few minutes writing the renamings. The upside is that if you now want to find everything that uses the external function getElementById, you can search for _that_, and you will find the "rename getElementById as get_element_by_id"[1] declaration, and then you know to search your project for get_element_by_id to find all the places where it's used. [1] I am not suggesting that particular syntax; I just picked something at random. The other upside is that if you want to find uses of the getFoobar function that's defined in your project, you just have to search for getFoobar rather than doing a case-insensitive regex search for "_*g_*e_*t_*f_*o_*o_*b_*a_*r_*". (Or, if your answer to that is to use language-specific tooling, that you aren't forced to use language-specific tooling when it might be more convenient to do searches on the GitHub website, or in the text editor / IDE that everyone else on your team uses, or in the text editor / IDE that you'd been using for years before starting to use Nim.) To me, this seems like an obviously better design. I don't want people who have spent years becoming productive in Emacs, or Vim, or Visual Studio, or whatever, to have to choose between using some different set of tools they aren't used to and having the searching operations they're used to using silently do the wrong thing. Am I missing something? Because, rightly or wrongly, this one weird design decision is enough to keep Nim off my list of languages that are worth the time to investigate: not because this single thing makes that much difference on its own (though it does feel as if it would make my life substantially worse, if I were writing a lot of code in Nim) but because I feel like the language is designed by someone who makes weirdly terrible design decisions sometimes, and if that's what I want then I already have C++ and Javascript :-).
      - cb321 4y ago
        Suggested in the Mega Thread (a few times): https://github.com/nim-lang/RFCs/issues/456#issuecomment-1114171802 https://github.com/nim-lang/RFCs/issues/456#issuecomment-111... https://github.com/nim-lang/RFCs/issues/456#issuecomment-1118538921 https://github.com/nim-lang/RFCs/issues/456#issuecomment-111... etc.
      - xigoi 4y ago
- 000ooo000 4y ago
  Carmack's tweet seems like more of a thought provoking question than an indictment of case sensitivity. I'm not sure I am convinced that a child stumbling over case sensitivity is a smoking gun. I just explained it to my nontechnical partner and before I had finished and proposed a "what do you think?" kind of question, she had given a "oh,hmm" to the idea that "abc" and "ABC" might mean the same thing when used as variables. Again, no smoking gun here either.
pa7x1 4y ago
The only situation I can imagine this causing a problem in your codebase is if you intentionally want to mix camelCase and snake_case in your codebase and these 2 meaning different things. So if you don't enforce in your codebase a specific code style practice and you would like someFunction and some_function to coexist and mean different things, then yes. Nim's approach is problematic for you. If you enforce a code style or, if you don't but you would convene that someFunction and some_function should mean the same thing in your codebase. Then nim's approach should be transparent to you.
- overthrow 4y ago
  It also makes it harder to grep. If you're on a team of 10 devs someone could have accidentally forgotten an underscore sometime last year. So you can't just grep for 'ready_for_upload', you have to use 'ready_?for_?upload'
  - michaelsbradley 4y ago
    Use nimgrep?
    - overthrow 4y ago
      Can you integrate that into an IDE? In many IDEs, if you hit ctrl-shift-f, it will search the project for the selected text with just one keystroke. Can vscode be made to Do The Right Thing for Nim without extra fiddling on every search?
      - michaelsbradley 4y ago
        Good question, but I don't know the answer (yet) because I don't use vscode, sorry.
      - Manabu-eo 4y ago
        Your Nim project will be in a consistent casing, otherwise the compiler will be warning you about inconsistent spelling. Regular Ctrl-shift-f will work just fine.
michaelsbradley 4y ago
I was annoyed by it at first, but got past that, and now don’t think too much about it. With tooling support (mainly lang server and nimgrep) I haven’t found it to get in the way, and have come to appreciate the flexibility it provides.
planetis 4y ago
I have extensively used Nim for the past 6 years, and it has never been an issue. I have seen codebases where someone wrongly capitalized a variable identifier, which results in a compiler warning being raised. So no harm done.
tryptophan 4y ago
I cant think of a single situation in which I would want take_action() and Take_Action() to do different things inside of a program. What reasonable purpose would naming things that way serve? I see it as a mandated style checker built into the language.
- IshKebab 4y ago
  Nobody wants codebases with different take_action() and Take_Action() functions. That's a straw man. The issues are: 1. Difficult to search code. Even just case insensitivity makes this worse because often you do have names that only differ in case (but in an acceptable way, e.g. they're different kinds of thing, or namespaces). But ignoring underscores makes it much much harder - now every search needs to be a regex. You can say "use an IDE!" and you absolutely should but you still sometimes need to search with dumb grep style tools. 2. Case insensitive rules are always more complex and difficult to remember. Where do they apply? All identifiers or just variables? What about keywords. Nim's rule is especially complex. It adds cognitive load. 3. Extra bike shedding. I imagine they added it to avoid bike shedding? But it will have the opposite effect. They should have just made a language wide convention like Rust. Nobody debates case style in Rust or indentation style in Go because the tooling and community pretty much force one style. I fully anticipate a Nim linter that bans style variation from the canonical one. If that doesn't exist already.
  - xigoi 4y ago
    > They should have just made a language wide convention like Rust. I don't know about Rust, but Python has a language-wide convention – and programs still violate it, including the standard library.
    - runarberg 4y ago
      In JavaScript (the wild west of programing languages) when I see a library that exports names in non-idiomatic ways, or otherwise has a non-idiomatic API, I usually search for a different library.
chomp 4y ago
Most of my complaints about this went away with --styleCheck:error. You might already know about this flag, but some people do not. Most projects I have found stick pretty closely to NEP1.
treeform 4y ago
Style insensitivity does not really come up once you start using the language.
nrclark 4y ago
I agree. It's one of my biggest gripes with the language. It has big effects on greppability. And by extension, it also has effects on search-engines. Both large ones like Google, and small ones like Github's or StackExchange's built-in engines. Even browser-search on an API document could be problematic. If I'm looking for some example code that uses my_testfunction(), I can't just search for "my_testfunction nim". Instead I have to add MyTestFunction, my_test_function, MYTESTFUNCTION, etc. The case-insensitivity isn't really a big deal, but the underscore-insensitivity is. If I'm honest, I think this is a big problem for adoption of the language. It's incompatible with a lot of search-engines, and weird to anybody coming from any other programming language. Nim should take advantage of the 2.0 release to do a compatibility break in this area, maybe with a compiler flag to enable the legacy behavior.
- Tommstein 4y ago
  > If I'm honest, I think this is a big problem for adoption of the language. Can confirm, it single-handedly kept me away from the language.
- xigoi 4y ago
  Pretty much all Nim projects use a consistent naming style, so this is not a problem in practice. > Nim should take advantage of the 2.0 release to do a compatibility break in this area, maybe with a compiler flag to enable the legacy behavior. No thanks, I don't want inconsistent naming conventions in my code.
- arc619 4y ago
  Your argument applies to style sensitivity as well to be fair - do you search for 'MyTestFunction' or 'my_TestFunction'... or was it 'My_TestFunction', maybe 'm_Y_tEsT_fUnCtION'? Style insensitivity lets you automate your local code (and/or through CI) to consistency for easy searching, even when external libraries YOLO their own style. > It's incompatible with a lot of search-engines Google and search engines are case insensitive, and mostly ignore underscores too. Let's be honest, how often would you just search for 'testfunction libraryname' on the web and get the signature you need? My experience from using the language in production for years is that case insensitive searches will find what I want in Nim code specifically because no one can use case/underscores to make things make unique. Instead, the language uses overloading through the type system to distinguish things. This is a far more succinct, safe, and expressive way of writing code from my perspective. It's worth noting that the first letter of an identifier is case sensitive, with the convention for types to start with a capital letter. So, you can write 'type Test = object' and 'proc test(t: Test)', then use them with 'var test: Test; test(test)' without any ambiguity, and with code completion/jump to source in VSCode (and others). If you then add 'proc test()' with no arguments, it's still unambiguous because the functions have different signatures, so you can then write 'test()' and your second function is called. If something is ambiguous, it's a compile time error. If you want, you can prefix modules like Python, but there's never any need. If you have two libraries with the API, same types, and function signatures (such as using two async libraries in the same program), you can just slap a generic '[T]' so it's lazily instantiated at the call site and move on. IMHO relying on casing/underscore to distinguish identifiers is objectively worse than using the type system to statically and unambiguously prove your intent, and normalising names removes a class of identifier confusion bugs to boot. Even style guides in case sensitive languages beg us not to use case and underscores to disambiguate symbols for the confusing code it creates, and to be honest, I've yet to see a compelling argument in favour of case sensitivity beyond simply being what people are used to.
Tommstein 4y ago
Same. Was strongly considering getting into Nim, but screw that, not interested in needing special tooling for something as basic as reliably grepping Nim code, there's too many other languages out there.
- otherme123 4y ago
  In this thread there are people who say "a convention is enough", but then don't give enough credit to the Nim convention. Maybe you are imagining a Nim library abusing this ability, and the same developer writing all different versions allowed: write_file, writefile, writeFile, w_ri_tefil_e... Nim developers are as smart as any other, and they like and write clean codebases adhering to the convention in NEP1. The ability to mix cases is used to fix libraries without having to disrupt their users. I've seen this kind of complains over and over: a new language emerges (e.g. Python 20-30 years ago), and what people finds the absolute showstopper is the indents instead or braces, a minimal part of the language that should not bother a competent programmer at all. The same people that were writting old PHP or old Perl, go figure, complainig that Python whitespace is ugly.

I think the opposite. Case sensitivity beyond the first character just makes life difficult.

It's a big plus for library and FFI interop so external styles don't take over your entire project. Also, John Carmack: https://mobile.twitter.com/id_aa_carmack/status/1592560938208710659 https://mobile.twitter.com/id_aa_carmack/status/159256093820...

IshKebab 4y ago
Plenty of programming languages have "did you mean xxx?" in error messages. Plus using IDEs means you will mostly autocomplete identifiers anyway. I don't buy it.
- otherme123 4y ago
  The point is to use third party libraries while keeping your prefered case in your code. You prefer your code in CamelCase, but some other guy made a library in snake_case. Still you can use the library using CamelCase, and not mixing. E.g. The Python Selenium library used to be in CamelCase, while almost all code in Python is snake_case. By using Selenium you ended up with code like: my_button = browser.getElementById("Button") They rewrote the whole library to be in snake_case, a change that forced a lot of code rewrite downstream. Even the Python builtin library has case inconsistencies (logging module is camelCase, sys has both alllowercase and snake_case) that weren't fixed even in 2to3. Nim would have handle this efortlessly, allowing you to use get_element_by_id or getElementById in the old library, and avoiding you the effort to rewrite your code if the Selenium mantainers decided for a case change. You can refactor your case without fear of making life worse for your users.
  - gjm11 4y ago
    An alternative design would be: when you bring in an external library, there's a mechanism to rename the symbols in it. The downside is that for each library you want to do this to, _once_ you have to spend a few minutes writing the renamings. The upside is that if you now want to find everything that uses the external function getElementById, you can search for _that_, and you will find the "rename getElementById as get_element_by_id"[1] declaration, and then you know to search your project for get_element_by_id to find all the places where it's used. [1] I am not suggesting that particular syntax; I just picked something at random. The other upside is that if you want to find uses of the getFoobar function that's defined in your project, you just have to search for getFoobar rather than doing a case-insensitive regex search for "_*g_*e_*t_*f_*o_*o_*b_*a_*r_*". (Or, if your answer to that is to use language-specific tooling, that you aren't forced to use language-specific tooling when it might be more convenient to do searches on the GitHub website, or in the text editor / IDE that everyone else on your team uses, or in the text editor / IDE that you'd been using for years before starting to use Nim.) To me, this seems like an obviously better design. I don't want people who have spent years becoming productive in Emacs, or Vim, or Visual Studio, or whatever, to have to choose between using some different set of tools they aren't used to and having the searching operations they're used to using silently do the wrong thing. Am I missing something? Because, rightly or wrongly, this one weird design decision is enough to keep Nim off my list of languages that are worth the time to investigate: not because this single thing makes that much difference on its own (though it does feel as if it would make my life substantially worse, if I were writing a lot of code in Nim) but because I feel like the language is designed by someone who makes weirdly terrible design decisions sometimes, and if that's what I want then I already have C++ and Javascript :-).
    - cb321 4y ago
      Suggested in the Mega Thread (a few times): https://github.com/nim-lang/RFCs/issues/456#issuecomment-1114171802 https://github.com/nim-lang/RFCs/issues/456#issuecomment-111... https://github.com/nim-lang/RFCs/issues/456#issuecomment-1118538921 https://github.com/nim-lang/RFCs/issues/456#issuecomment-111... etc.
    - xigoi 4y ago
000ooo000 4y ago
Carmack's tweet seems like more of a thought provoking question than an indictment of case sensitivity. I'm not sure I am convinced that a child stumbling over case sensitivity is a smoking gun. I just explained it to my nontechnical partner and before I had finished and proposed a "what do you think?" kind of question, she had given a "oh,hmm" to the idea that "abc" and "ABC" might mean the same thing when used as variables. Again, no smoking gun here either.

pa7x1 4y ago

The only situation I can imagine this causing a problem in your codebase is if you intentionally want to mix camelCase and snake_case in your codebase and these 2 meaning different things. So if you don't enforce in your codebase a specific code style practice and you would like someFunction and some_function to coexist and mean different things, then yes. Nim's approach is problematic for you. If you enforce a code style or, if you don't but you would convene that someFunction and some_function should mean the same thing in your codebase. Then nim's approach should be transparent to you.

overthrow 4y ago
It also makes it harder to grep. If you're on a team of 10 devs someone could have accidentally forgotten an underscore sometime last year. So you can't just grep for 'ready_for_upload', you have to use 'ready_?for_?upload'
- michaelsbradley 4y ago
  Use nimgrep?
  - overthrow 4y ago
    Can you integrate that into an IDE? In many IDEs, if you hit ctrl-shift-f, it will search the project for the selected text with just one keystroke. Can vscode be made to Do The Right Thing for Nim without extra fiddling on every search?
    - michaelsbradley 4y ago
      Good question, but I don't know the answer (yet) because I don't use vscode, sorry.
    - Manabu-eo 4y ago
      Your Nim project will be in a consistent casing, otherwise the compiler will be warning you about inconsistent spelling. Regular Ctrl-shift-f will work just fine.

michaelsbradley 4y ago

I was annoyed by it at first, but got past that, and now don’t think too much about it. With tooling support (mainly lang server and nimgrep) I haven’t found it to get in the way, and have come to appreciate the flexibility it provides.

planetis 4y ago

I have extensively used Nim for the past 6 years, and it has never been an issue. I have seen codebases where someone wrongly capitalized a variable identifier, which results in a compiler warning being raised. So no harm done.

tryptophan 4y ago

I cant think of a single situation in which I would want take_action() and Take_Action() to do different things inside of a program. What reasonable purpose would naming things that way serve? I see it as a mandated style checker built into the language.

IshKebab 4y ago
Nobody wants codebases with different take_action() and Take_Action() functions. That's a straw man. The issues are: 1. Difficult to search code. Even just case insensitivity makes this worse because often you do have names that only differ in case (but in an acceptable way, e.g. they're different kinds of thing, or namespaces). But ignoring underscores makes it much much harder - now every search needs to be a regex. You can say "use an IDE!" and you absolutely should but you still sometimes need to search with dumb grep style tools. 2. Case insensitive rules are always more complex and difficult to remember. Where do they apply? All identifiers or just variables? What about keywords. Nim's rule is especially complex. It adds cognitive load. 3. Extra bike shedding. I imagine they added it to avoid bike shedding? But it will have the opposite effect. They should have just made a language wide convention like Rust. Nobody debates case style in Rust or indentation style in Go because the tooling and community pretty much force one style. I fully anticipate a Nim linter that bans style variation from the canonical one. If that doesn't exist already.
- xigoi 4y ago
  > They should have just made a language wide convention like Rust. I don't know about Rust, but Python has a language-wide convention – and programs still violate it, including the standard library.
  - runarberg 4y ago
    In JavaScript (the wild west of programing languages) when I see a library that exports names in non-idiomatic ways, or otherwise has a non-idiomatic API, I usually search for a different library.

chomp 4y ago

Most of my complaints about this went away with --styleCheck:error. You might already know about this flag, but some people do not. Most projects I have found stick pretty closely to NEP1.

treeform 4y ago

Style insensitivity does not really come up once you start using the language.

nrclark 4y ago

I agree. It's one of my biggest gripes with the language. It has big effects on greppability. And by extension, it also has effects on search-engines. Both large ones like Google, and small ones like Github's or StackExchange's built-in engines. Even browser-search on an API document could be problematic. If I'm looking for some example code that uses my_testfunction(), I can't just search for "my_testfunction nim". Instead I have to add MyTestFunction, my_test_function, MYTESTFUNCTION, etc. The case-insensitivity isn't really a big deal, but the underscore-insensitivity is. If I'm honest, I think this is a big problem for adoption of the language. It's incompatible with a lot of search-engines, and weird to anybody coming from any other programming language. Nim should take advantage of the 2.0 release to do a compatibility break in this area, maybe with a compiler flag to enable the legacy behavior.

Tommstein 4y ago
> If I'm honest, I think this is a big problem for adoption of the language. Can confirm, it single-handedly kept me away from the language.
xigoi 4y ago
Pretty much all Nim projects use a consistent naming style, so this is not a problem in practice. > Nim should take advantage of the 2.0 release to do a compatibility break in this area, maybe with a compiler flag to enable the legacy behavior. No thanks, I don't want inconsistent naming conventions in my code.
arc619 4y ago
Your argument applies to style sensitivity as well to be fair - do you search for 'MyTestFunction' or 'my_TestFunction'... or was it 'My_TestFunction', maybe 'm_Y_tEsT_fUnCtION'? Style insensitivity lets you automate your local code (and/or through CI) to consistency for easy searching, even when external libraries YOLO their own style. > It's incompatible with a lot of search-engines Google and search engines are case insensitive, and mostly ignore underscores too. Let's be honest, how often would you just search for 'testfunction libraryname' on the web and get the signature you need? My experience from using the language in production for years is that case insensitive searches will find what I want in Nim code specifically because no one can use case/underscores to make things make unique. Instead, the language uses overloading through the type system to distinguish things. This is a far more succinct, safe, and expressive way of writing code from my perspective. It's worth noting that the first letter of an identifier is case sensitive, with the convention for types to start with a capital letter. So, you can write 'type Test = object' and 'proc test(t: Test)', then use them with 'var test: Test; test(test)' without any ambiguity, and with code completion/jump to source in VSCode (and others). If you then add 'proc test()' with no arguments, it's still unambiguous because the functions have different signatures, so you can then write 'test()' and your second function is called. If something is ambiguous, it's a compile time error. If you want, you can prefix modules like Python, but there's never any need. If you have two libraries with the API, same types, and function signatures (such as using two async libraries in the same program), you can just slap a generic '[T]' so it's lazily instantiated at the call site and move on. IMHO relying on casing/underscore to distinguish identifiers is objectively worse than using the type system to statically and unambiguously prove your intent, and normalising names removes a class of identifier confusion bugs to boot. Even style guides in case sensitive languages beg us not to use case and underscores to disambiguate symbols for the confusing code it creates, and to be honest, I've yet to see a compelling argument in favour of case sensitivity beyond simply being what people are used to.

Tommstein 4y ago

Same. Was strongly considering getting into Nim, but screw that, not interested in needing special tooling for something as basic as reliably grepping Nim code, there's too many other languages out there.

otherme123 4y ago
In this thread there are people who say "a convention is enough", but then don't give enough credit to the Nim convention. Maybe you are imagining a Nim library abusing this ability, and the same developer writing all different versions allowed: write_file, writefile, writeFile, w_ri_tefil_e... Nim developers are as smart as any other, and they like and write clean codebases adhering to the convention in NEP1. The ability to mix cases is used to fix libraries without having to disrupt their users. I've seen this kind of complains over and over: a new language emerges (e.g. Python 20-30 years ago), and what people finds the absolute showstopper is the indents instead or braces, a minimal part of the language that should not bother a competent programmer at all. The same people that were writting old PHP or old Perl, go figure, complainig that Python whitespace is ugly.