I don't get why people get so worked up over this. It's not a "little" benefit in my opinion. In regards to drawbacks I can only see one, and that is grepping for the identifiers becomes more difficult.

> It's not a "little" benefit in my opinion

Could you explain it, then? An identifier refers to a single thing. I don't see having multiple ways to refer to that identifier as a win AT ALL—it may be a win for people who are too lazy to learn their own code base, but it makes code hard to read, hard to maintain, and hard to refactor.

Meanwhile, having an identifier unique makes it easy to index, easy to manipulate.

I don't understand why you think it makes code hard to read. In what situation would a code base use fooBar and foo_bar as two different identifiers meaning two completely different things? The idea behind this "style insensitivity" is that amyAtePizza has the same meaning as amy_ate_pizza. Why should it be distinguished in a programming language?

> In what situation would a code base use fooBar and foo_bar as two different identifiers meaning two completely different things?

You don't. It's a terrible idea to mix naming conventions.

> amyAtePizza has the same meaning as amy_ate_pizza.

WHY?! What possible benefit could it have? Why would you be mixing styles in the first case? Why can't you just remember which style hopefully your entire code base uses?

I wouldn't mix styles inside my own code base. But what if I am using somebody else's library which uses a different style? The benefit is that I can then use the style I have been using in my code base to call the functions in that library without mixing naming conventions.

I hope you never move code between different code bases, then.

Wouldn't it be a lot simpler to have a single style?

I think it will put more cognitive load on the humans who read the code. Instead of doing a quick visual comparison to see if identifiers are the same, programmers will need to actually comprehend the two tokens, and then transform them in their head to see if they are the same. This sounds minor, but I think the cognitive load can add up. Visually comparing two tokens is not quite conscious thought, while comprehension is. It's something you'll always need to think about when reading code.

You don't understand how having multiple highly-different forms for each name is harder to read? People read a token at a time whenever possible.

Nobody is arguing that you should be able to use multiple forms for different variables. They're arguing that you shouldn't use multiple forms at all.

When I present myself to people I use one form of my name. Some people I know use nicks. Others use part of my formal name. Due to me being a foreigner, essentially everybody I know uses a slightly different way to name me or pronounce the same name. However, there is consistency. Each person will use the same form for naming me.

This happens with Nim code too. Each programmer will have their convention, and will use it consistently. If you have a team, you establish a convention for the project: you need that anyway because people creating new stuff need a consistent way of naming things and you don't want to later rename everything after a heated discussion. So if you can't keep people on your team from using a project convention, you have a bigger problem than slightly different identifiers in a programming language.

Also, once you start using the different free naming conventions in Nim you grow inmune to them looking ugly. Just like when you know only one programming language everything else looks alien, but when you learn something else you expand your horizon and it stops looking so alien, and it stops being "harder to read". I jump from one convention to another without problem for each project as needed, and doesn't even bother me at all.

tl;dr it's not a big deal, don't let that stop you from learning a very nice language, you could regret it later