[beagle3]

It's possible to argue about this endlessly from a theoretical perspective, but Nim is not a new language, there are substantial code bases (not as substantial as C, Java or Python, of course, but still substantial), and these rules have been worked out through real world cases, and are very effective in practice.

From a theoretical perspective, your argument can equally be applied to C's case sensitivity or Pascal's case insensitivity when someone "doesn't know" or "forgets" about the equivalece - isn't it absurd that FOO and foo are different (C) / equivalent (Pascal) when you are coming from the other one? Similarly, Lisp-1 vs. Lisp-2 . In practice, it's just one more convention -- among several others.

The motivation is not to get rid of __unwanted___crap___ (nim bans multiple sequential underscores and leading underscores, so they are rid of), but rather: Nim arguably has the best built-in FFI of any modern language with nontrivial use, and this FFI has been a factor in the language design. Nim's rules allow you to keep a mostly uniform coding style in _your_ parts, yet integrate it naturally into projects using snake_case, CamelCase, javaCase and ALLCAPSCASE and SHOUTING_MATCH_CASE, or all of the above in the same project.

Nim started out case-insensitive (which is less popular, but definitely common choice made e.g. by Pascal, Excel and others). IIRC, the "first letter's case does matter" is a relatively recent addition (as in, 2 years out of the project's 9) to simplify FFI to conventions like OpenGL, which have the same identifier in both lower or upper case.

In theory, everything could go wrong. In practice, Nim gets it exceptionally right.

[kazinator]

Are you saying that the FFI transparently renames identifiers, so you think you're calling foo_bar, but the actual foreign function is FooBar, with no traces of FooBar in the program (like in some definition which indicates that the two are mapped together)?

If so, that's an incredibly bad idea.

If a program calls some foreign function called FooBar, the identifier FooBar better appear somewhere in it, if you know what's good for the maintainer seven years from now.

[beagle3]

The “real” name and argument types of an FFI must appear at least once, but other than that the identifier follows Nim equivalence rules.

Again, the theory can be argued endlessly. In practice, it just works.

[kazinator]

Ah, but does the real name appear together with the Nim name in some line of code that binds them together, which your editor can jump to if you want to know where that Nim name is defined?

If it's just some construct that defines a call to FooBar in the foreign library, with no mention of foo_bar, but elsewhere in the Nim code we call it as foo_bar, I'm afraid I cannot agree with this being a good technical decision in language design.

I wouldn't sign off on such a concealment ruse even if it were someone's macro, not being upstreamed into a language implementation at all.

[beagle3]

That _is_ the nim name. It's just case-and-underscore insensitive so you definitely can if your editor is Nim aware (at the very least emacs, vim and vscode have been aware for a long time; nimgrep is a command line tool similar to grep that is aware of nim's sensitivity rules.

You don't have to agree, you don't have to like it, you don't have to use Nim, and you don't have to think it's a good idea. But any reasonable sampling of real world use shows that it's not a bad technical decision. I don't think it shows it's a great technical decision either; It just shows that it's acceptable and comparable in mental and operational burden to any other decision.

It seems whether it is a little better or a little worse, it will take years of experiment to get any kind of statistical significance.

[kazinator]

> That _is_ the nim name.

Well, a nim name; there is no the nim name.

> you don't have to use Nim,

That would be the lucky situation for now; if we band together and write cogent criticisms, we may be able to keep it that way going forward.