People really care about weird stuff.

There is trade offs to both sensitivity and insensitivity. Just because you are used to one approach from your favorite programming language does not mean the other way is "wrong".

Want a consistent style? Use that nice --styleCheck:usages option. No problem at all.

Honestly, I think Nim should keep the current approach just to filter out certain people.

What are the arguments for insensitivity? I'm not used to it, and it seems to my rookie eyes that it only opens venues for confusion (forcing to pay closer attention to symbols to mentally "de duplicate" them), inconsistencies within a same/foreign code base that make joining a project/jumping into an external library just slightly harder, and more vim/emacs/tab/spaces jihads.

The main advantage is that you can follow a consistent style in your codebase even if your dependencies follow a different style, so you don't have a situation like in Python where if you use the unittest module, you're forced into not following PEP8.

It actually is something that gives me pause for thought. In my field of coding (finance) ambiguity is terrifying and eventually you get it wrong.

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.

You must remember that Nim is a statically typed compiled language with support for distinct types etc. This means that you wouldn't be able to call the wrong procedure if you didn't provide it the right types. Besides, not allowing similarly named but differently cased identifiers causes less ambiguity, not more.

I mean, it really might be fine. I've written maybe 20 lines of Nim in my life, what do I know.

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.

This is the opposite of a footgun. Imagine if DNS was case sensitive and GMAIL.COM belonged to a domain squatter.

Nim prevents that. It's that simple.

This is an interesting take, I do see the value. If I was trying to prevent this type of aliasing, I'd have the compiler throw an error if there were two aliased variables names (xyz and XYZ for example), rather than merging them automatically.

Since Nim is statically typed you can't simply create a new variable with the same name as an existing one without errors. You can shadow variables in a deeper scope, but then only the latest version is available. Defining a function xyz and then trying to define another function xyZ is indeed an error.

That's what --styleCheck:error is for.

No. Nim always throws an error if you try to define multiple variables/procs that are conflicting.

--styleCheck:error strictly enforces camel case.

Are you confusing syntax with semantics? Your hesitance seems to come from intuition and it's not uncommon for intuition to make mistakes like that.

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.

Yeah I can see how it might seem scary. It takes you out of your comfort zone and it's easy to start thinking uncomfortable things have to be scary. I've been using Nim for a couple of years now, and I've never run into a safety issue with it.

I'm all up for new, exciting, slightly scary but promising concepts in programming. Rust's borrow checker. Python extremely-dynamic syntax. Nim's "Python syntax, native code, GC" premise.

Exploring different ways to write the same name does not excite me.

Reading through the GitHub issue, it seems like the one place it makes sense in my eyes is that you can refer to stuff in external libraries with your convention even if the library uses a different one. I'm not sure if there's something I'm not thinking of, but to me it'd make sense if the library boundary was the only place it let you do it.

Style insensitivity is a safety feature, not a problem.

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.

I love Nim and wish it would take off and become as common as python. Case sensitivity isn't affecting that for me. But it still really irks me.

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.

In math, most variables are a single letter, so style sensitivity wouldn't really apply.

If it stopped at disallowing the similar names, I'd think it is quirky but fine. A little unusual but harmless, maybe even helpful as you say.

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.

The nice thing about being able to run others people code with your style is that your entire codebase stays in one consistent style. You don't run into issues like in other languages where one library author has done some dubious style choices which then propagates into your code. This was always a pain-point for me in Python.

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?

Dubious decisions in third-party libraries are common, but camel vs. snake case is probably not the main...

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>

> you often have quasi-singleton classes called "FooManager", then a single instance called "foo_manager".

Like this:

    type FooManager = object
    var foo_manager: FooManager

> Now... are these colliding? Or not, because the first letter _is_ case-sensitive?

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.

Not a nim user, but I wonder if the styleCheck:error or styleCheck:usages compiler flags would do what you're asking for.

> other people's code can, refer to the same thing by different names

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.

For me the biggest potential issue seems grepping probably. I guess that some other tool than ag, grep, etc has to be used for searching.

You can use --styleCheck:usages or a linter to ensure that the style is uniform.

> the automatic conversion from camel-case to snake-case... very much so.

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.

It’s probably my biggest gripe with nim. I hope they drop it and provide a tool like gofmt to get everyone’s code into the same style.

Why though? With this feature you're able to import a library in a style you don't like and still be able to use it in whichever style you prefer.

Nim has a tool called nimpretty similar to gofmt

As a frequent Nim user, I've tried it a few times and it doesn't seem to do much, other than reflow lines in not very logical places. I'd prefer an uncompromising formatter like Black/Prettier/StyLua.

gofmt doesn't seem to ensure consistency in naming styles.

My ideal would be to simply not allow having my_variable and myVariable in the same namespace but given that you can do that in essentially every language I sort of prefer that they have to refer to the same thing.

This is exactly what Nim does. If you try to define both my_var and myVar it will error out.

The benefit is to avoid confusing variables or procs named my_var, myVar and myvar.

If you define them both yes, but you're still free to use them both.

  var my_var = 1
  myVar += 1
  echo(my_var)

Will happily compile and give you 2. I'd prefer an error in that case because while I'm not liable to make that mistake but I could easily mistype long_variable_name as long_variablename without noticing and then cause myself problems when I try to grep.

  nim --styleCheck:error c x

This enforces the same capitalization style in your code:

  x.nim(1, 5) Error: 'my_var' should be: 'myVar'

Searching has never been a problem for me in years of using Nim but there is `nimgrep` bundled for style insensitive search. Also I'm no RE wiz, but seems like RE might help if it came down it.

Just to stress myself as an anecdote though, I have years in the language and it hasn't come up yet for me, and I've never needed to use `nimgrep`.

You can use --styleCheck:usages or a linter to ensure that the style is uniform.

You cane enable styleCheck:usages by default in the compiler. Also, most editors do variable/proc autocompletion.

Also you can use nimgrep if have to search across projects written by different people.