[goodpoint]

This complain comes from people who haven't used the language.

> Not to mention that reading code requires extra mental overhead (especially being new to the language), that `getAttr`, `get_attr`, etc., are actually the same thing.

On the contrary, the language prevents confusion due to mixing getAttr and get_attr in the same codebase and bugs from using the wrong one.

Unsurprisingly, many safety-critical environments have policies to enforce consistent naming styles.

The linter will convert both to "getAttr" and the compiler will complain if the user tries to define the same proc twice.

[lifthrasiir]

There are two kinds of case-insensitivity in identifiers. In either cases identifier cases (and in this case, also underscores) are normalized, but case-agnostic languages would allow any mix of them while case-pedantic languages would disallow any pair of identifiers normalizing into the same name (they may still give helpful errors based on that normalized name though). I don't think case-agnostic languages provide a new value not provided by case-pedantic languages.

[goodpoint]

Nim provides the benefit of both: when interfacing with C libraries a case-agnostic language helps.

Yet, checks on function definition and types has the same benefit of case-pedantic language, without forcing a specific style on the developer.

[lifthrasiir]

It is okay to have a feature (NOT necessarily this feature) that translates other conventions to a single consistent convention; for example a language may convert a name "foo_bar" into "fooBar" when used in C bindings, preferably with an escape hatch. However case-agnostic languages do not try to do that, they give zero indication for what convention to use (cf. function names in PHP, which is a horrible mess). No single convention is better than others, but a single consistent convention does matter.