[Symmetry]

If you have 'myvar' and 'myVar' in some code there are three things you could do.

1) The compiler gives you an error, this would be my preferred solution though I'm not aware of any language that does that.

2) These end up referring to the same variable with no error. Nim's solution.

3) These are actually different variables with no error. The common solution.

Again, I would prefer (1) but I think that (2) is a safer way of handling the situation than (3).

[ASalazarMX]

As much as I hate it for correctness, 2 is better than 3 indeed. No sane developer encodes meaning in the case of the name of the variables, in the overwhelming majority of cases it's a typo.

[cb321]

In the C world ALL_CAPS very often signify preprocessor macro identifiers (or some other "class" of identifier), but, yeah..they may all be "insane". ;-)

[ASalazarMX]

OMG, what if C did significant case because of that? I mean, it's fine to write "#import", why didn't K&R use a special syntax for macros, like $MACRO or something and left the uppercase as a convention?

[cb321]

I am no C historian, but I believe part of the idea was to be able to have macro wrappers around proper language symbols like "#define sin(x) real_sin(x, 1e-7)" or some such, for example. The "warning character" (what you used `$` for) was thus only for introduction (#define) not for reference. Whether the initial intent or not, this idea certainly came to become an application, also invoked via compiler command line "-Dsin=real_sin" style definition. With this you want the case conventions/sensitivity to be the same in the preproc/macro language as the base language.

FWIW, I do think that the late 1960s saw a broad "new prog lang" evolution away from case insensitive (often ALL CAPS due to low resolution dot matrix printers/display devices) stylistic tendencies in, e.g. LISP and FORTRAN, towards case sensitivity and lowercase. So, I suspect this was the salient driver - "We have lowercase now/text is more legible! Let's use it!". (Yes, mechanical typewriters/typesetting had it for decades to centuries, but programming was not done on those, but with printers and punch cards and just starting to be on CRTs.) There are analogies with Unicode in PLs these days (though there are obviously also other motivations these days/decades with the compute world i18n).

[DangitBobby]

player = Player()

all the time in Python.

date = new Date()

all the time in JS.

Those are just the two languages I spend the most time in, but, but I'm sure it's trivial to find numerous examples of cases carying meaning in case-sensitive languages. Especially ones which encourage camel casing.

[narimiran]

`player` and `Player` are different in Nim. Ditto for `date` and `Date`.

[silok]

There is a difference between variables and types.

For instance, in C#, with capital-case convention for variables, it is common to give a variable the same name as the type.

eg `public Player Player;`

[BiteCode_dev]

The 3rd solution is terrible, because:

    ForMid = 4 # padding for middle box in px

And:

    FormId = 3 # ID of the form in the user process

Should definitely not be resolved as the same variable.

[DangitBobby]

The only thing worse than 3 is 2.

[beagle3]

I don’t remember the exact options, but there’s a way to make Nim emit warnings (and perhaps errors) for inconsistent capitalization.

It isn’t the default, though.

[cb321]

The options are nim c --styleCheck:hint --styleCheck:usages (you need both). Though not on by default you could put it in your config.nims or nim.cfg's to make it on by default for you or for your code.