I was hoping case sensitivity would be implemented but it seems like it was too controversial. I'm thinking at this point there might be too much resistance.
Case sensitivity is worse in every way IMO. Look at Nim's implementation of UFCS, which means `foo(bar) == bar.foo`. This means only one possible `foo` that takes type of `bar` can be invoked. There's no ambiguity if `foo` is a method, a proc, or a field - if there were, you'd get a compile time error.
Similarly, case insensitivity, of course, means `foo == fOO == fOo == foO`. Reducing these to one identifier means less ambiguity to the programmer and encourages either using sensible names that can't easily be confused, and/or unambiguous mechanisms like the type system designed for this purpose.
Say you have a constant for 'light enabled' Instead of naming it `lEn`, it's better to use `type LightState = enum disabled, enabled` and write `light.set enabled` for so many reasons. Same goes for pretty much everything. It's worth noting as well that the language is very good at resolving overloads by type, so if you have your own object and create a `len` for it, it's not going to get confused with the string `len` or even a `lEn` constant. Even if you have a `lEn` and `len` that are used in the same context with the same types (why though), you can qualify it anyway with `module1.lEn` or `module2.len`.
The language has so many easy tools to make things more explicit and easier to read at the same time. Ultimately, case sensitivity only really ends up encouraging bad naming practice without adding anything back.
The `--styleCheck:error` flag can be passed to make everything follow NEP1 style guide [0].
`--styleCheck:usages` can also be passed to instead make identifiers follow their original naming (Basically turning off style insensitivity)
I think I agree with Carmack on this. I'm hyper aware of case now, but this was probably the major cause of errors for me when learning (didn't help that tooling was less good then, so there were no linters pointing out my errors).
I guess for me it's one of those things I got tripped up on initially but came to appreciate later. It taught me how to be more precise about characters and reasoning about them in code.
There's also cases where case sensitivity should matter in naming in my experience, and it's not possible without it.
Personally this preciseness is just a distraction, but it sounds like you have learned from the constraints and can now take the training wheels off again.
Very curious about those cases, yet to find one myself that was not because of a bad design decision. Though I am also very big on the idea of `ambiguous grammar, rigorous implementation`, for natural language too. (Toki Pona is a somewhat extreme example but the contextual grammar, and holistic minimalism is fascinating)
I've come to increasingly accept it over time? I mean, I'd really like it if my_function() and myFunction() just weren't allowed in the same section of code but if you allow the user to have both it's probably better that they refer to the same function than different functions.
Imo it goes beyond that. You have folks from Java etc. coming over with their camel-case as well as python folks with snake-case.
Now despite both of them writing in their own styles, their code can interact, because when the java-programmer gives you a `validateObject` procedure from their package, the python developer can just use it as `validate_object`.
Not being forced into other people's style choices is a really nice boon to me.
It's not so much that anybody thinks that mix is a good idea, but it's just what happens immediately in any C/C++ codebase if you're using any nontrivial combination of libraries at all. The feature is about providing consistency, not ignoring it.
It's apparent from the RFC discussion that there is no consensus on the topic. With little (proven) tangible benefit of making the change, and a large potential for backlash within the small existing community, I'm not certain it's worth the risk for Nim to make this move.
Agree to disagree. I don't want to force my users to use snake-case just because I use camel-case and vice versa.
There's options to turn it off, options to turn it into a warning when you have style issues so you can make them consistent and it prevents similar names that shouldn't exist in the first place by causing compiler errors (if you have is_ok you should not have isOk in the same scope, what are you doing). It is just not a big deal, at all. And as stated, it is not hard to ensure consistency within your codebase by heeding compiler warnings/errors.
As someone who has been writing nim for many years now, using grep, rg, and various other search tools I can say that I've never had any issues with finding things I wanted. This is just one of those imagined issues that your realize doesn't exist when you actually try to do it.
As someone who has never explored nim but was was just about to follow the link, you have effectively convinced me to not bother. I can imagine the arguments for case insensitivity (not agree with them but I could live with them for certain tradeoffs), I can't find a place in my brain where "underscore insensitivity" could have existed as a concept before reading those words.
Its not an actual issue, it is the projected experience of another language and/or IDE/ tooling. Fyi the newest GitHub ignore case. But I have been using grep with nim code daily and it was not an issue.
That actually makes whitespace syntax in Nim much better. Can't recall the number of times I copied Python code snippets and had to track down lurking tabs.
You can't mix tabs and spaces in the same file since Python 3, which completely solves this problem without imposing one or the other choice on the users.
To be fair, you can tell your IDE to just turn tabs into spaces and call it a day, that's an issue for all of 5 minutes.
What you can't do is tell your IDE to interpret camel-case as snake-case if you want (or vice versa), just because this package you really need uses camel-case and you want to use snake-case.
> It's apparent from the RFC discussion that there is no consensus on the topic.
That's your take? I can see a couple of actual nim users complaining, the rest are some randos that tried to derail any productive discussion with "I have an old C library that uses three different styles for init, how would I bind it to Nim?" and although a bunch of workarounds exist, they were too loud and stubborn. For me it showed that most nimmers prefer style insensitivity as an option, although they don't use it in the same project.
I didn't know this existed. There's a lot I like about Nim, but total rejection of tab indentation, and now this style insensitivity thing, mean that for me personally, Nim will just stay an interesting language I see on HN from time to time.
It's one of those things that, as a Nim hobbyist programmer, I think is a neat feature to have, but I could see being a big hesitation for use in professional environments.
Given that you tend to use linters in those environments as well and that you can turn it off anyway, I'd disagree on that one. There are other factors that would make me hesitate in a professional environment much more, such as community size and talentpool.
Similarly, case insensitivity, of course, means `foo == fOO == fOo == foO`. Reducing these to one identifier means less ambiguity to the programmer and encourages either using sensible names that can't easily be confused, and/or unambiguous mechanisms like the type system designed for this purpose.
Say you have a constant for 'light enabled' Instead of naming it `lEn`, it's better to use `type LightState = enum disabled, enabled` and write `light.set enabled` for so many reasons. Same goes for pretty much everything. It's worth noting as well that the language is very good at resolving overloads by type, so if you have your own object and create a `len` for it, it's not going to get confused with the string `len` or even a `lEn` constant. Even if you have a `lEn` and `len` that are used in the same context with the same types (why though), you can qualify it anyway with `module1.lEn` or `module2.len`.
The language has so many easy tools to make things more explicit and easier to read at the same time. Ultimately, case sensitivity only really ends up encouraging bad naming practice without adding anything back.