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.

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.

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.

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

First, you are aware of `--styleCheck:usages` and `--styleCheck:off|hint|error` that by default already warns the user if he is not consistent on the spellings of identifiers? So you ever just have to search by one form inside your projects.

As far as renaming external libraries goes, if the original name is get_foobar, and the project uses snakeCase, I would be very surprised if it's renamed to anything other than getFoobar. There are slightly more tricky stuff like get_ID, but even then there are only a couple of reasonable forms to search for. And it's rare to be searching for things you haven't seen used, and if you saw it used you know how it's spelled in that library.

I've been programming for years in Nim and never had any problem grepping or searching for things because the style insensitivity.

I don't think it's reasonable to force every developer to spend a few minutes writing renamings if virtually all of them are obvious mechanical transformations, just because a paranoia not substantiated by experience.

Suggested in the Mega Thread (a few times): https://github.com/nim-lang/RFCs/issues/456#issuecomment-111... https://github.com/nim-lang/RFCs/issues/456#issuecomment-111... etc.

> 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_"

Are you seriously expecting that someone will put an underscore in the middle of a word?

I'm not expecting anyone to turn getfoobar into getf_oobar, no. But (1) there are cases where people might disagree about whether something is one word or two (do you want to bet no one has written "white_space" where you wrote "whitespace"?) and (2) there are weird cases where the same string of letters can be split into words (or sufficiently word-like pieces) in multiple ways.

I don't have a plausible example of #2 in mind. Maybe there aren't any. (There are definitely lots of things that break into words in multiple ways, of course, but maybe there aren't any that make plausible identifier names more than one way. Though for what it's worth I bet there are.) And in any given case you can check, given a few seconds' thought, that there aren't other possibilities. But that little extra cognitive load is a bigger deal than it sounds like -- it's a distraction from other things -- and if you don't do the check then you'll never know whether your search operation actually found everything it should have.

So you can check by eye every time. Or you can write the ugly regexp every time. Or you can just accept that what ought to be a perfectly simple operation isn't quite right and might invisibly go wrong some time.

That's not a set of options I like.

> The point is to use third party libraries while keeping your prefered case in your code.

Third party Nim libraries? Because if the all used the same style this would never be needed in the first place.

Rust never has this issue because everyone uses the same style.

Bleh I don't like snake_case, it results in long identifiers