Maybe it's not so bad in practice, but looking from the outside, I think... really? To be specific, case-insensitivity doesn't bother me, but the automatic conversion from camel-case to snake-case... very much so.
I just look at it and see a foot and a gun pointing at it. The arguments for it sound to me like "it's fine, there's a safety and a clever mechanism that prevents shooting yourself in the foot".
Maybe it's all fine, but I'd for one feel more comfortable if the gun wasn't pointing at the foot in the first place.
Exploring different ways to write the same name does not excite me.
Nim prevents that. It's that simple.
--styleCheck:error strictly enforces camel case.
Having a single syntax with multiple semantic meanings would indeed be a foot gun.
I can't think of a way how different syntax translating to a single semantic meaning could cause any concern. It's not like the wrong thing can happen, it just might look differently depending on codebase.
It prevents bugs where a developer mistakes one variable or proc for another having similar names.
For example in another language you might have variables isReady, isready, is_ready and use the wrong one, leading to a bug.
Nim does not allow defining 3 different variables like that.
But that I can, and other people's code can, refer to the same thing by different names, is a bridge too far.
Like I say, it won't deter me from trying the language, probably (I've been saying it for a while), but certainly doesn't make me more keen to try it.
And I'm not certain what scenarios you envisage where this would be an issue, why do you care how other people call your functions?
I care about how a function is called because so much tooling around programming is effectively grep. I can grep for a function name and get a pretty good idea where it is called. There's also a million variants of grep - git grep, unholy regular expressions (recently I used one to find all instances where foo is called with exactly 2, not 3 params, in Python), IDE plugins and so on. GitHub search? Google search for exceptions?
IIRC Nim comes with some kind of "nim-grep" that is camel-vs-snake-aware, but that doesn't fix all the other tools.
The minor gripe, additionally, is that you often have quasi-singleton classes called "FooManager", then a single instance called "foo_manager". Now... are these colliding? Or not, because the first letter _is_ case-sensitive? What does "fooManager" map to then?
In my utility function, this feature gives me nothing but concerns. But then again, I'm not (yet?) a user the Nim community provides for so... <meh>
Like this:
type FooManager = object
var foo_manager: FooManager
Well as you correctly reason, the first letter's case distinguishes them.
Convention in the language is for types to start with a capital letter and instances start with a lower case letter.
> What does "fooManager" map to then?
It maps to the `foo_manager` instance because underscores are ignored, they're just for you. By the way, underscores are exceedingly rarely used in Nim code because they're not semantically significant, why bother.
Still, if you like you can use them in your code, and others can choose not to as they want. Clashing identifiers are a compile error so no worries.
They can but the compiler will just tell you it's ambiguous and to qualify it. Also bear in mind Nim has very strong static typing, so for things to clash they also have to have exactly the same type, otherwise no worries.
You can even rename symbols on import or force qualification for all symbols, but I've never needed to do either in years of heavily using the language.
There are times when you might want to use the same variables in different cases (math), and the assumption that you wouldn't seems like nannying to me.
Also, fundamentally, it's a very english-centric view and encourages that by default. I'd prefer case assumptions weren't implicitly baked into the language at a basic level.
I guess for me I just feel like a character is a character and I don't want the language telling me I should view it differently.
If an identifier clashes, you get a compile time ambiguity error. It means `is_OK` and `isOk` will report ambiguous identifiers and force you to qualify it or rename it.
This also helps further reduce ambiguity indirectly by forcing sensible naming.