"Style insensitivity" means that in Nim the following identifiers are treated as equivalent: nOpenFiles, no_pen_files, Nope_NFiles. Insertion and removal of underscores, as well as case, is ignored. I hope you weren't expecting to find anything in your codebase using grep.
It seems a reasonable guess that, oh, maybe 99% of people wondering why Nim is "case/style insensitive" are more worried about "style insensitivity" than about mere "case insensitivity". (The other 1% haven't yet learned that Nim is "style insensitive".)
Nim also allows passing by non-const reference without any indication of such at the call site. Also it has semantic indentation, which is cute and clean-looking but more effort to safely edit than the popular alternatives.
Everything I see in Nim is designed around being clever. Even in the documentation they have clever extensions to BNF syntax that save such precious characters.
It almost looks like you're suggesting that `a -b` will be parsed as a*(-b). Let me just clarify, that is not the case. With the 'strongSpaces' feature, `a -b` results in a compile-time error. Without that feature, it works as expected (`a-b`).
> Nim also allows passing by non-const reference without any indication of such at the call site.
Why is this a problem?
> Also it has semantic indentation, which is cute and clean-looking but more effort to safely edit than the popular alternatives.
Could you give an example of how exactly semantic indentation makes the language less safe? I have been using Nim (and Python) for years and have not found this to be the case.
But it seems that doesn't matter. Some people really like it, and perhaps some interesting new feature will come out of it and benefit the world.
This is what nimgrep [1] and nimsuggest [2] are for.
That said, it is still expected to use a consistent style within your codebase. The feature exists so that third-party libraries with a non-standard style can be used without style changes in your codebase.
One of the fundamental truths I've learned over my decades of designing software for consumption by other developers is if you enable them to do the stupid thing, they will do the stupid thing. Expectations aren't really anything meaningful without enforcement.
The problem is that they go out of their way to add some batshit crazy stuff like this, or cripple themselves without a reason, when they could be so much better with small and simple additions.
Would it be so difficult for Javascript to not ever have those crazy silent coercion rules and have lexical scoping by default? It would have been a trivial compiler change back in 199x when JS was designed.
Would it be so difficult for Golang to have a proper generics system from the start and be done with it?
Would it be so difficult for Java to add closures 10 or so years ago?
etc...
C to have been designed with a proper string type...
Size of array not part of its type for Pascal?
Fucking named constants in CSS?
They should probably fix the wording of this -- as an outsider I can't really parse the message conveyed here. If it doesn't create C code then why does the comparison matter? Or is it just about the "ansi" part? But then why does that matter?)
'not nil' sounds like a great addition to the language, but what if you wanted that to be the default behavior without having to pepper it throughout every variable in your codebase?
Are the binaries hosted on SourceForge?
