This is very much a question that has been going around my mind for a while. I've seen many people wince when hearing about this feature and with v1.0 closer than ever before, it may be time to have an official vote to decide whether Nim should remain style insensitive or whether it should become case sensitive.
So what does everyone think. In particular those that are using Nim every day, is this a waste of time or is it something that will seriously help Nim's adoption?
Please speak your mind in this thread. And preferable state either "I want a vote" or "I do not want a vote" somewhere in your reply.
Style insensitivity isn't a problem for me. Even if you'd remove it, personally I'd be fine with it. However this: https://github.com/nim-lang/Nim/wiki/Unofficial-FAQ#why-is-it-caseunderscore-insensitive explains the design choice and I feel like it's worthwhile to stick to this as the only one complaining about it seem to be people just glancing over Nim instead of giving it thought.
Nim remains the most readable language I've ever seen and I love it for it, maybe add the above mentioned answer to the official FAQ? Or a short blogpost calming the fear of those who hate it? Basically I want a vote for keeping style insensitivity.
I want a vote, more data is better.
I don't care that much about the feature, if anything I'd be OK with doing away with it, as it's unfamiliar to most programmers and not a big win, IMO. Leaving it in wouldn't make me upset either, I'll reserve my displeasure for more egregious examples (method I'm looking at you!) of waste.
It would be good to get a sense of how much code would break if style insensitivity was removed. Really, for any change, there ought to be such an assessment.
Offtop. I want a vote, but whats the point in this keyphrase if it is ambiguous by itself and thus grepping it will tell nothing? Instead it should be either "I'm a pedantic nerd" or "It should work, don't care how, still I'm a nerd" :). Non nerds should not be allowed to vote at all :D.
I do not want a vote. As GULPF wrote, Nim needs stability. Breaking compatibility to fix language warts is beneficial as long as it happens occasionally.
A lot of people express concern about style insensitivity fearing that it leads to inconsistent naming withing the same project or even file. I think that what Nim needs is a real-time linter/formatter that removes inconsistent and incorrect naming on the fly.
I don't care about a vote. I prefer to trust @Araq and the core team.
My view: get out of my way and don't enforce "religious" rulings on me. I'm perfectly willing to accept clear rules on var/type/etc. naming but I think it's inacceptable, not defendable, and not in our interest to (a) allow willy nilly freedom (as in underscore vs CamelCase) and at the same time to (b) have the compiler change names.
Afaic
If I write "var foo_bar ... proc fooBar(..." I don't want to have problems CREATED BY THE COMPILER.
When comparing Linux which has case sensitive file names and Windows that doesn't, Windows is easier. Both have their conventions but it's easier when you have some flexibility. Similarly, having Nim take care of style is nice and convenient.
The note in the wiki is quite reasonable and so is the feature. Most importantly, it gives you the freedom to write your code the way you want. Each organization can have their own way and the language gives you that flexibility. Now, Nim has its own convention to keep things consistent as an organization - NEP1 and all - but you don't need to adhere with that thanks to style insensitivity.
It took me some time to understand the motivation and I am for it. Overall, this hasn't affected me in all the Nim code I've read and written so far.
I'd argue that it should be completely insensitive (leading _ is okay since you encounter that with wrapping all the time) and I'm against removing the feature.
[...] with v1.0 closer than ever before [...]
That's a very complex theological claim. I for one will only believe in v1.0 if I see it, before I die.
it may be time to have an official vote
That's a very complex political claim. Is Nim a democracy now? Are votes to be somehow weighed by merit, or does some useless gadfly philosopher like me get as much decision-making power as someone who had actually contributed dozens of useful modules? What if some nutjob recruits his nutty friends to come in and stuff the ballot box?
In short: I do not want a vote.
I think his eminence Godemperor Andreas should do whatever he wants, and anyone who doesn't agree can go fork themselves.
to decide whether Nim should remain style insensitive or whether it should become case sensitive.
I think there are more than two choices for what can happen when the compiler notices the existence of conflicting variations that normalize to the same identifier (fooBar and foo_bar):
Any option other than 2 gives Nim an advantage over most other languages. Some of those would adversely affect compile times to varying degrees.
I think the current behavior is great, but if Andreas decides to change it, I'm sure his reasons would be vastly more sophisticated than mine.
In practice you get people complaining about not being able to name their variables the same as their types pretty quickly. Nim used to solve this by using "P" and "T" prefixes ala Pascal/Delphi:
type
TPerson = object
name: string
age: int
var person: TPerson
person.name = "Bob"
People see this sort of thing immediately and it was off-putting as well to some people.
I'm one of those. I still sometimes find myself starting types with 'T'. But I don't feel that to be a problem. And anyway, a rule that says that types must start with a capital letter makes sense and is easily within what a language can reasonably demand.
Style insensitivity, however, always looked willy nilly to me, just an arbitrary rule made by the creator(s) of Nim.
As someone who has been Nim programming for just over a week now, I really don't mind this feature at all. I would consider myself to be a more open minded programmer though, I actually rather enjoy typing lots of (((( and )))) in LISP...
As a novice (to the language) my first impressions about style insensitivity have been:
No, style insensitivity does not allow your to do what you want. The reason being that the language behind the scenes changes identifiers. The correct and honest way to say it is that Nim gives you less freedom (in that regard).
Look: e.g. in C (and many other languages) you can have two identifiers "foo_bar" and "fooBar" and they are two different things. In Nim, however, they are just two names for the same thing.
It certainly does give me more freedom to make the code look and read the way I want it to in my nim source files, does it not? If person x wants snake case in his library, but I only use camel case in my coding convention, I can just write his identifiers as if they were camel case, correct?
And if the code functions the way I would like it to as well, why should I care that the compiler changed something behind the scenes? As a new nim user, is there a use case I need to know about where that is important?
Yeah, I guess almost everyone will do let person: Person = blah blah.
But shouldn't Types and Variables have different namespaces?
This isn't dealbreaking, just feel it's silly to have case sensitivity only on the first letter.
Yes and no. Yes if the libraries are written in Nim but no, when they are not. But: If they are written in Nim they can be both, snake_case or camelCase because Nim makes no difference.
Also note that than Nim can import C libraries and use any identifier style you prefer anyway.
The trade off is that you get a tiny bit more freedom in the case you don't like a Nim libraries style but you get uncertainty and confusion because the compiler does not differentiate.
Maybe the difference in our points of view is due to you preferring more liberty (no matter whether it's actually useful) while I prefer safety and a compiler not playing tricks behind my back.