Should we get rid of style insensitivity?
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.**
Re: Should we get rid of style insensitivity?
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](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.
Re: Should we get rid of 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.
Re: Should we get rid of style insensitivity?
* \+ When i'm in the middle of a problem and my head is boiling already, I really don't want to remember how exactly to spell RunLoop or Runloop, DataBase or Database, fileName or filename, etc. * \+ When i'm debugging with add_echo-compile-run-repeat approach and I want to do this stupidly fast, I appreciate when Nim forgives me a typo in `echo myDebugiNformation` and doesn't waste my time by failing the build. * \+ I've never wasted my time to find that my grep search didn't show all the needed results. Maybe I was lucky? Guess not, given how many other issues I found in nim. * \- Rarely I find inconsistencies as a result, when reviewing the code. So I can fix those if I feel like it :). 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.
Re: Should we get rid of style insensitivity?
I think it would be a mistake to get rid of style sensitivity. It's a nice feature once you get used to it. Besides, Nim needs **stability** , not yet another breaking language change.
Re: Should we get rid of style insensitivity?
I'm OK with case insensitivity, but I still find the underscore insensitivity a bit weird. It didn't cause me any real problems though.
Re: Should we get rid of style insensitivity?
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.
Re: Should we get rid of style insensitivity?
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 * leading underscore for var names is OK * make reasonable rules (like Types capital first letter, vars and procs not) * DO NOT CHANGE ANYTHING BEHIND MY BACK!!! If I write "var foo_bar ... proc fooBar(..." I don't want to have problems CREATED BY THE COMPILER. * The compiler should be our friend. It should be alert and tough on rules and help me spot problems but it should not, not ever, _create_ problems.
Re: Should we get rid of style insensitivity?
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.
Re: Should we get rid of style insensitivity?
> [...] 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]([https://voat.co/v/programming/2853775](https://voat.co/v/programming/2853775)) 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](https://en.wikipedia.org/wiki/Fork_\(software_development\)) 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`): * It can silently treat them as the same identifier (Nim's current behavior). * It can silently treat them as different identifiers (like most other languages). * It can generate a warning, but treat them as same identifier. * It can generate a warning, but treat them as different identifiers. * It can generate an error - and recommend a nice auto-refactoring tool. * It can be even more insensitive, ex `ф00бар` (unidecode, deleet, unemoji). 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.
Re: Should we get rid of style insensitivity?
I have no issues with the feature. Sometimes as yglukhov said, it reduces the pressure of getting it right the first time when you are in a hurry. I read these comments too, but how many people actually using nim has an issue with that? Not the idea itself, but the execution? I can't think of a situation in which I lamented nim's approach.
Re: Should we get rid of style insensitivity?
Hmm, my personal review.. I adjusted to it in 2 days, ofc before adjusting i thinked its shit xD I know Nim needs a buff in community, but It is only a turnout for someone who refuses to invest 2 days in nim and if he is that much lazy we probably dont need them
Re: Should we get rid of style insensitivity?
I'm too "casual" to submit a relevant opinion, I just want to add a little "-" to the yglukhov enumeration : Insensitivity can scares newcomers. Most languages are fully sensitive and most people are used to include the style as a part of the identifier and to use the style to reduce the need to find names. I don't know if it's a good practise but it's like a little barrier for newcomers. You'll need to show them practical examples to give a proof of how the insensitivity is better. @Ar : You can read old topics. Like this as instance [https://forum.nim-lang.org/t/2390](https://forum.nim-lang.org/t/2390)
Re: Should we get rid of style insensitivity?
I do not want a vote. * There's no reason to believe that a random set of users will make a better decision than the core team. * Nim has other, more pressing, problems. As to the second question, whether style insensitivity is a good idea: * Inside the same module: no it isn't. For a language which lets me cast anything to everything, I want unique identifiers. * Between modules: yes it is. I would be fine with automatic id aliasing if it was limited to `import`, `importc` and `importcpp` and if it was opt-in so I could use my own identifier style in my own module.
Re: Should we get rid of style insensitivity?
Style insensitivity is my least favourite feature. That said, I also don't want a vote. I'd rather have a stable 1.0 sooner instead of another language change
Re: Should we get rid of style insensitivity?
I am OK with the current state - I don't want a vote. If Andreas wants to change it I am OK with it too.
Re: Should we get rid of style insensitivity?
I don't want a vote. It's a great feature that already saved me many hours of unproductive discussion. There are more pressing topics to focus on to v1.0
Re: Should we get rid of style insensitivity?
I think @Libman and @gemath are on to something in suggesting that the
programmer should be able to decide how to handle insensitivity. To help Nim's
adoption, I'd say by default the compiler should generate warnings when
"insensitivity is detected", but you could later switch warnings off
--warning[insensitivity]:off
Run
(leading to current behaviour) or turn them into errors
--sensitiveMode:on
Run
And more fine-grainedly with some module import pragma:
import {.insensitively.} foo, bar
Run
Helping the "sensitive-minded" newcomers would be a PR win for Nim: It would
send a clear signal that the customer's voice is being listened.
I don't see voting in this forum relevant, because the results would be heavily
biased; For every active Nim user in here who is already used to syntax
insensitivity, there are 1 potential Nim users out there who are not used
to it. You should rather ask them.
Personally I would rather see stripped-down stable 1.0 later than a bloated
unstable 1.0 sooner.
Re: Should we get rid of style insensitivity?
I think a vote with two options is not sufficient to find out, what users really need. Maybe the rule for identifier equality should get adjusted to give users more freedom in naming things: A leading and trailing underscore should be allowed. I guess there are some users coming for example from C, C++ or Python, who are used to have such underscores as part of their naming convention and they don't want to be forced to change it.
Re: Should we get rid of style insensitivity?
I have not used nim for a while, mostly because my current project is in typescript, now, wouldn't it be easier if I wrote TypeScript? Case sensitivity helps readability and code maintainability, and If I remember well, nim team always believed that the language should be assisted by a proper editor or IDE. It would be easier to analyse and refactor code with case sensitivity than without. Currently developers are allowed to choose different styles to write variable and function names, without having the compiler complaining about it, and one may argue that this is productive, but in reality, and specially in big projects (that import and borrow code from other code bases) it's not (it's a nightmare), imagine a developer jumping between different code bases and reading the same function called in different styles each time (getData(), get_data(), getdata(), gEtDaTa()) Compilers aren't there only to convert syntax into bytes code, it's in their duties to ensure code validity and consistency, this helps later the next developer trying to extend and maintain the code. Having the compiler enforcing case sensitivity helps improving Nim's readability, and its adoption in big projects, So I'm voting yes for case sensitivity.
Re: Should we get rid of style insensitivity?
**I don 't want a vote** Human can read a word even it's in cmplete form. The must important is not style-readibility but flow-readibility. Style-readibility is superficial reasoning to mislead the actual issue when a code is badly written. Considering at current stage, stability is more important than "sensitivity-religious" arguments.
Re: Should we get rid of style insensitivity?
**I don 't want a vote** I agree with GULPF too. You should work on stability, Would you please stop chasing perfection and start hardening what you already have ?
Re: Should we get rid of style insensitivity?
I have to agree with the general sentiment here. I do not want a vote. Stability of 1.0 is far more important. @Dom96 can I ask you about some more context for this? > I've seen many people wince when hearing about this feature Where have you seen this? I ask because, outside of the normal reddit / hackernews complainers, I haven't seen this to be such a big problem, but that could be my limited view of the world. Where you able to determine why these people where so put off by this feature? Was it just a gut reaction to an unfamiliar paradigm, or is it something else?
Re: Should we get rid of style insensitivity?
I would have been interested in a vote, but apparently I'm the minority ;). Personally I find the case insensitivity very off-putting and it was one of the reasons why I stayed away from Nim the first times I came across it. > I appreciate when Nim forgives me a typo That's my main concern about it. I like consistency, and I don't want inconsistent naming in my code base. I want the compiler to help me get it right exactly. I never saw it as a feature, rather a quirk that I can live with. Yet, sometimes I still feel like I'm manually doing the work of the compiler when I'm double checking that I use consistent style. And I get distracted when reading foreign Nim code that switches between equivalent names for no apparent reason, especially when done in a local scope, where the syntax becomes obviously inferior to a consistent naming.
Re: Should we get rid of style insensitivity?
I want a vote, more data is better. I also don’t think it matters. I would rather core devs focused on fixing bugs and “real” problems. But a simple vote is not hard. I think being consistent with other languages is good. This is where I favor strict case sensitivity. But I also think trying out new things is cool too. This is where I favor nim's crazy thing. Just you know for trying? It has personally not impacted me in any way. Maybe it’s like a no-op feature. Personally if I was making a language I would not put it in.
Re: Should we get rid of style insensitivity?
> I like consistency, and I don't want inconsistent naming in my code base. I > want the compiler to help me get it right exactly. stylecheck option is > supposed to do that
Re: Should we get rid of style insensitivity?
I don't know if this is clear or not but if you want consistency, you actually want how Nim works today. Say you start a project tomorrow and your idea of style consistency is cAmelCase, you can use the Nim stdlib happily. But the moment you import a library authored by someone whose idea of consistency is snake_case, you will be annoyed that your code looks inconsistent. Or you won't use the lib and be handicapped or not use Nim at all. If your idea of consistency is snake_case, you won't like Nim or many libraries since cAmelCase is Nim's idea of consistency. Given how Nim works today, it removes this conflict altogether. I think it's a great feature. I can use snake_case or cAmelCase, however I prefer and not be bothered by what Nim or any library does. My code looks how I like and I use any external lib, however it is, in my style. I don't see why this is a perceived negatively. The more uptight you are about how your code should look - i.e. consistency, the more impressive Nim's position on this is.
Re: Should we get rid of style insensitivity?
Here is my opinion: **I want a vote**. I understand the merits of style insensitivity and I've argued for these merits for multiple years now. I want to keep this short, so in summary, what it really boils down for me is: * **Educating newcomers about style insensitivity is and always will be a constant time drain.** I argue that removing this feature will save us all A LOT of time in the long run. Far more time than the feature's merits actually save me in development time. I think I can safely say that everyone was sceptical when they first learned of style insensitivity. Yes, it isn't a problem, but it makes people hesitate. Nim has strong competition and it's already hard enough to sell a non-Google/Mozilla/Apple-backed language to someone. **I want Nim to be successful and I do fear that any obstacles to adoption will be the death of it.** It would actually be in my interest to keep the style insensitivity, given that a change would deprecate some portions of my book.
Re: Should we get rid of style insensitivity?
> @Dom96 can I ask you about some more context for this? The context is multiple things: * I've been speaking to more and more people recently about Nim, discussed their experiences selling it to other programmers and the conclusion seems to be similar. Style insensitivity is awkward and they would rather not have to explain this to everyone. * If I am pitching Nim to someone I try to stay away from telling them about style insensitivity and I know of many others who do the same, that's a pretty bad sign I think. * I am conscious of the fact that v1.0 is coming and I want to ensure that Nim has a solid chance of gaining adoption. I view style insensitivity as a possible major blocker. > Where have you seen this? I ask because, outside of the normal reddit / > hackernews complainers, I haven't seen this to be such a big problem, but > that could be my limited view of the world. > > Where you able to determine why these people where so put off by this > feature? Was it just a gut reaction to an unfamiliar paradigm, or is it > something else? Note: This is mostly conjecture. It's not something that programmer's feel needs to be solved. The explanation of why the feature exists doesn't merit it. It's a fundamental aspect of the language that's only there to make it possible to use your favourite style. In practice people don't care about that, or they view code which uses different conventions as bad quality and just refuse to use it.
Re: Should we get rid of style insensitivity?
> I don't know if this is clear or not but if you want consistency, you > actually want how Nim works today. That is the theory, but in practice it's a little more complex thanks to the additional rule which makes the _first letter of any identifier case sensitive_. A library developer decides their types need to be prefixed with ` wx` (`wxBox`, `wxLine` etc.) because the original library does it and I'm forced to use those types in exactly that style... so much for consistency. > When comparing Linux which has case sensitive file names and Windows that > doesn't, Windows is easier. Sure. It's easier to use, for normal users. But we are programmers, we've grown up to notice any small differences in our identifiers.
Re: Should we get rid of style insensitivity?
I totally appreciate the effort involved in education but this is a good feature. It might help to enhance the wiki entry and perhaps point to this forum thread and anyone who complains can be redirected. They can then decide on their own whether they agree or not. This is a Nim legacy and whoever uses Nim either likes this or has made their peace, I don't think it is a good reason to kill it just because people don't see its potential. Also, if there is a vote, my vote is to liberalize further - no restrictions with _ and case sensitive first letter. I don't know of a good reason to maintain those. Remove those restrictions and allow the feature to truly give users the ability to do what they want. Nim can still have its preferred style but that is self-discipline, not enforced. Just like Go decided to keep things super simple - it works great for some, not for me. I'm using macros to do some really cool things, can't do that in Go. Making a choice does limit market share, no doubt, but there is space for everything and I believe Nim is already successful. If you don't intend to have Nim pay your bills, market share is irrelevant. It is a passion and already solves thousands of problems without making any compromises on programmer or system efficiency. People who need that will hunt for it and find it. In other languages, you have no choice. With Nim you do and that will appeal to some.
Re: Should we get rid of style insensitivity?
@treeform > I want a vote, more data is better. Just like the light bulb Nim wasn't invented by a democratic vote. It was created by one particular smart man. Had there been a vote on the internet how a new language should be the outcome might have been quite different. Maybe something like Rust. But gladly it wasn't like that. Gladly it was one man who got it 95% right (seen from the perspective of probably the vast majority of Nim developers). @bluenote > Personally I find the case insensitivity very off-putting and it was one of > the reasons why I stayed away from Nim the first times I came across it. It (plus the CamelCase, snake_case issue) also is illogical in a way. Reason: Static typing in a major part is about "nailing down exactly what you want". Not "well, uhm, kind of a number" but "an integer. Unsigned. 16 bits. value range between 1 and 25321. Immutable (with let)". So I find it utterly illogical to have Myvar, myvar, MyVar,My_var, my_var, My_Var, all boiling down to one and the same. At the same time, of course, I understand that many want easy going at least in many cases. My personal choice how to address that would be to keep it the "easy going" way it currently is but to add a "strict" pragma for cases where one wants strict and tight Case sensitive, no funny '_' names. @dom96 I agree with your "I want a vote" post - minus the vote part. Sorry if this gets a bit graphic and "political": We've seen where a mistaken "democracy" leads with linux whose creator has pulled out and more and more people with many priorities - al of them irrelevant and untechnical - are gaining influence and power. We also have seen how exceptionally well the benevolent dictator model has served Python. I don't want a vote. 99% of votes are irrelevant and often based on questionable subjective priorities. Including mine. What we have is almost perfect: We the mere mortals can tell our concerns and wishes and needs - and the benevolent dictator @Araq who created Nim in the first place and did that damn well decides. He alone. Or maybe with a couple of core people. Those who seriously disagree - and are willing to put considerable knowledge and work behind their words - can fork and create their own Nim. No vote from me. Opinions, wishes, maybe even pleas, yes, but no vote. All power to Araq who has shown plenty that he makes good decisions. Amen.
Re: Should we get rid of style insensitivity?
@moerm > So I find it utterly illogical to have Myvar, myvar, MyVar,My_var, my_var, > My_Var, all boiling down to one and the same. They are not one and the same. The first letter is case-sensitive. * * * @shashlick > my vote is to liberalize further - no restrictions with (...) case sensitive > first letter. I don't know of a good reason to maintain those No no no. I know a good reason for case sensitive first letter, and it is crucial: Types names have upper first letter (and people should adhere to this!), variables, functions, etc. have lower first letter. And this allows for stuff like `person: Person`, etc.
Re: Should we get rid of style insensitivity?
@miran Oops, my bad, you are right. But I guess one can get my point anyway. TL;DR: The name of something should be what the developer writes. Period. And: I happen to be a convinced fan of case sensitivity but I can understand the arguments of the other side (and can live well with both).
Re: Should we get rid of style insensitivity?
I think what everybody is missing is that it's not about "we can make it work", but about removing the weakest (easiest to attack) surfaces in "let's adopt Nim discussions". I like the insensitivity and it seems like a smart choice, but if I have to choose between this and 15 other good Nim features, I'll let the sensitivity go: Nim has many cooler things that I want people to use. On the other hand, I think supporting a default setting which can generate an error if a label is used in a non NEP1 way in a project might be a good enough fix: * it makes a self-contained project almost case-sensitive by default * it still lets people use the imports with the naming they want, or turn it off
Re: Should we get rid of style insensitivity?
> Just like the light bulb Nim wasn't invented by a democratic vote. It was > created by one particular smart man. Every great invention was built on the shoulders of giants, and the light bulb is no exception. Attributing it to a single man is misleading. This also goes for Nim. Araq doesn't make decisions in isolation. Nim is a community driven effort, let's not pretend it would be alive without the many great contributors from around the world who spend their time creating PRs, writing issues and arguing on forums :)
Re: Should we get rid of style insensitivity?
Style insensitivity is bad when you try to use tools like grep, sed etc. and it also confuses a lot of people. **I want a vote.**
Re: Should we get rid of style insensitivity?
Just a fresh example: I was searching for a function in someone's github repo and I couldn't find it - guess why - the author used camel case in the examples while it was defined with snake case in the code. This feature only caused me issues so far.
Re: Should we get rid of style insensitivity?
> Every great invention was built on the shoulders of giants, and the light > bulb is no exception. Attributing it to a single man is misleading. Correct. But: Out of billions of people only a select few did invent or create things. Others could have stood on the same shoulders of giants - but didn't and couldn't. As for Araq, I didn't mean or think that he decides in isolation. In fact, I'm sure that he listens to us users/developers and considers many arguments before making a decision. Finally, _no_ I do not forget you and other contributors. I _thank_ you and I _value_ your great work. I just also see that while you contribute much more than most of us, what you still is based on the foundation laid by Araq. My reason for lauding Araq is that he made the right and smart decisions when designing Nim and that he laid the foundation. But again, I understand perfectly well that you and some others made and make a lot based on that foundation and I thank you for that. @idobai grep -i
Re: Should we get rid of style insensitivity?
I like the idea of a vote **not** because I believe that language design is some kind of democracy (really, where do people get these ideas?) but because language design is partly UI design, UI design is guided by users, and one way to get user feedback is a vote. Ideally, it would be more than a thumbs up/down. As I said, for me, the feature is not very important either way, I mostly don't like it, but it doesn't make me turn away from Nim. As @dom96 said, 1.0 is on the way, and the time to clean up warts is before a 1.0 is released.
Re: Should we get rid of style insensitivity?
@moerm grep -i is not style-insensitive, it's only case-insensitive which means it'll be useless most of the time. This feature shouldn't be in any language.
Re: Should we get rid of style insensitivity?
> I like the idea of a vote not because I believe that language design is some > kind of democracy (really, where do people get these ideas?) but because > language design is partly UI design, UI design is guided by users, and one > way to get user feedback is a vote. Agree 100%
Re: Should we get rid of style insensitivity?
And that's why there is a nimgrep.
Re: Should we get rid of style insensitivity?
No, keep it. Style insensitivity is nice and quite easy to understand. Dumbing down Nim is a road to nowhere. BTW Nim style insensitivity is an eccentric feature but not unique: [http://mozart-dev.sourceforge.net/xl_features.html#namestyle](http://mozart-dev.sourceforge.net/xl_features.html#namestyle) I do not want a vote.
Re: Should we get rid of style insensitivity?
Do you plan to implement nimgrep for github and IDEs too? Btw, removing this "feature" wouldn't dumb down Nim because this feature is already dumb - the fact that we need to change our standard tools for its mythical benefits already tells a lot about the ecosystem for an outsider.
Re: Should we get rid of style insensitivity?
Let's then remove _ as a digit separator because of grep.
Re: Should we get rid of style insensitivity?
I think a vote is good, will be voting no for the change though
Re: Should we get rid of style insensitivity?
"Let's then remove _ as a digit separator because of grep." \- It's not as common to grep for numerical values as for names. I don't care much if there's a vote or not, but I really don't think it should be changed. But I do think Nim should issue warnings about difference in style though. I think it should mainly be used as a way to allow people to have less of a mental overhead when programming and debugging. But it would be nice to encourage people to take a pass over the code later, so it's more pleasant to read and easier to debug. Maybe a gofmt-like tool could help people align this
Re: Should we get rid of style insensitivity?
I was just dealing with case typos in a C++ program this morning. I wasted a few minutes with stupid mistakes. It is making me consider converting the whole thing to Nim because of that and other issues. The FAQ on this is totally correct. You absolutely should not get rid of this style insensitivity. It is a significant improvement on language design that Nim has made. MyName and Myname should not be considered two different things and you should not enable people to operate like that. I think you should consider the responses here to be votes. I do not think you should use some polling feature or site to create a vote because that encourages drive by votes from people who just are unfamiliar with the feature and dislike it just because of that. People want things to be the way they are used to and their brains automatically rationalize whatever that is. If people want to vote they should have used Nim for a bit and come in here and state their case. Which actually then we should explain why they are wrong if they say to change it.
Re: Should we get rid of style insensitivity?
One more thing. If there is no warning then I think by default there should be a warning about style inconsistency which people can turn off if they want, maybe the warning says how to turn it off. As far as user adoption / feedback, I think that the extraordinary efforts that a small number of people have made should be applauded. Like I mentioned my theory is that the core problem is really about a surface level judgement that people have against things that are unfamiliar. Or maybe style inconsistency is just an easy concrete thing to pick when someone asks about adoption. The real answer may be just that it seems different and requires a lot of effort to learn new things. So if my theory is correct then by removing style inconsistency, that would remove that complaint but not necessarily increase adoption. The feedback would probably just pick on something else that is different as an excuse. You could A/B test by giving different talks and then looking at the feedback, but again that could be misleading because measuring actual adoption takes months if it's even possible.
Re: Should we get rid of style insensitivity?
I'm against changing this, and I think a vote is superfluous so **I do not want a vote**. When I first found Nim I though the style insensitivity was a bit strange. But the more I use it the more I like it. And after having had to write some code in C and Ruby that doesn't have it I'm even more for it. The fact of the matter is that you will never be able to get 100% of people to write in one style (and even if you did, is it dataBase or database, fileName or filename?), so all code that isn't style insensitive will be at risk of ending up as a mixed style project. It only takes one "bad" import. Sure you can fix this by making a lot of bindings, but why would you, when you can have style insensitivity for free. Besides, apart from the ubiquitous object/instance differentiation (which Nim also has an exception for) it's widely regarded to be a bad idea to have style-sensitive identifiers anyways. Having a variable fileName and a procedure filename would just be confusing. The only case that can be made here is that an identifier like word1_word2 would collide with wo_rd1word2 which is a problem for a very small set of word combinations where both would be normal names but not the same. Couldn't think of any example of this though. Besides style sensitivity is a relatively new concept. The only reason we have snake-case is because spaces can't be used in identifiers, and the only reason we have upper case letters as separate characters is that the ASCII group decided that it would result in safer encoding. The alternative was sending "Hello" as "Hello". The choice was made as missing the would mean the entire rest of the document would be upper-case, which would be annoying.
Re: Should we get rid of style insensitivity?
For me, this idea of voting is strange and even makes me uncomfortable. Does the creator of the language agree with this procedure? If this is not the case, we are following a wrong path here. Moreover, are we going to vote for each presumably controversial topic, for instance the syntactically significant indentation? If would be the logical next step, but I’m not sure it will do any good to the language which will quickly look like some of these committee languages with lot of compromises to please a majority of users. In fact, this is the first time I see such a fuss about case insensitivity. Before C, most languages were case insensitive. Now, if you choose insensitivity, you have to suffer recriminations from some users and have to justify why you don’t do as C does. It looks like programmers are getting more conservative nowadays. Personally, I have used case sensitive and case insensitive languages without any problems. In both case, I write code in an insensitive way, following the style guide if it exists. Using case to differentiate identifiers is really the wrong thing to do. So, I can switch between Python and Nim without any difficulty despite Python being case sensitive (which, I think, is not the best choice for a language with implicit declaration). Of course, case sensitivity is simpler for the user but may cause lot of problems later if someone misuses it. And we can be sure, it will happen. So case insensitivity is a better choice to avoid any problem. The only drawback are possible variations in the spelling of identifiers, but it can be solved with appropriate tools. So, no vote for me. There are most important topics and this case sensitivity vs case insensitivity topic tends to become a little too much of a religious affair.
Re: Should we get rid of style insensitivity?
Case typos are not a big issue. Compilers errors messages will points you in the right line. If you import C identifiers (or other languages) style insensitivity may introduce hard to find bugs. In some cases the compiler can silently replace a_thing by aThing . It's less common than typos, but it can takes lot of time to find because the program works without errors. I don't ask for removing insensitivity, maybe it has more benefits than annoyances, I don't know. Do what you want but for newcomers, or bad programmers like me, please add a warning, or recommend people to change the names from foreign languages files.
Re: Should we get rid of style insensitivity?
I'm for not voting. As said previously this appears to be more of a religious-like issue more than anything else. For me, an amateur hobbyist programmer, I'm in favor of case insensitivity, however ignoring the underscores does seem to be more non-intuitive. On a similar note, Nim has Uniform Function Call Syntax with the addition of being able to call procedures without parentheses. This allows one to get the length of a string four different ways. For myself this was a much harder adoption as a new user when compared to case insensitivity. My concern is that a vote on case insensitivity could very easily lead to a vote on this feature as well, and I've personally come to appreciate this feature a lot more than case insensitivity. If that were to happen, a vote on removing some of the other of Nim's stand-out features could be next... In addition, these are features that make Nim more enjoyable to program with, which I suspect was one of the goals originally, and they give more choice/flexibility to the programmer.
Re: Should we get rid of style insensitivity?
Personally I do not care either way. To me the issue of case sensitivity or not has never been one that existed. For me personally the biggest problem is time :D - however had, past that point, I may wish to be able to use a "sub-dialect" of nim that is more light-weight in syntax. For example, things such as not having to use "var" to declare local variables and things like that. I love syntactic flexibilty but I understand that this is not on the roadmap towards 1.x.
Re: Should we get rid of style insensitivity?
PS: Can we not edit our own posts? I did want to edit it to clarify what I meant ... but I can not see an edit-button or so. I only see "reply", a heart icon, and the time ... quite strange forum here. Is it written in nim? :) I swear this also changes every some months... :P
Re: Should we get rid of style insensitivity?
PMunch wrote: > And after having had to write some code in C and Ruby that doesn't have it > I'm > even more for it. I can not speak for C but in ruby you can make use of aliases. So: > def foo_bar end; alias foobar foo_bar This may be excessive to want to do so manually but you could batch-generate aliases to these methods on your own. It is not the same as having it on the same top-level support for the whole language (to compile it), but since the claim was that "ruby does not have style insensitivity", I feel that claim is ... weird because you could enforce it in different ways, probably even making use of rubocop's autocorrect option once you setup a style guide (either by also adding aliases as is perhaps, or using ruby code to do so).
Re: Should we get rid of style insensitivity?
I just read that dom prefers "I want a vote" or "I don't want a vote", but actually I don't really care about the style insensitivity either way. I think many people who dislike it do so largely because they think of it as "impure" for people to have to care about style sensitivity (e. g. you are a noob if you were to rely on case sensitivity, such as PHP). I myself do not see it that way simply because I actually think that the issue is between the human being, and the parser/lexer. So if it is not necessary, why should the parser care? I give you another example. Python mandates () for methods; in ruby the () are optional unless something is ambigous. I prefer the ruby way. Why? First, you can use the () anyway in ruby so you get the same as in python, except for in python they are MANDATORY. And I really hate mandatory syntax rules that restrict me in how I operate. It is for a similar reason I hate python's mandatory indent, since I can not copy/paste into the interactive python. This is why I think the style insensitivity is not really an issue save for people who think about "purity" of a language. But I don't really care either way enough to even want a vote, or not want a vote. There are so many other things to improve!
Re: Should we get rid of style insensitivity?
> PS: Can we not edit our own posts? You can, don't you see a pencil button on your post?
Re: Should we get rid of style insensitivity?
**I do not want a vote** , however, I think that "the decision makers" should read the thread and see if any arguments stand out to them or change their view and do what they feel best. That being said, I like @LibMan's third suggested option... * The compiler should generate a warning, but treat them as same identifier. That gives developers the freedom to focus on functional code but give the most anal retentive programmers the ability to quickly find and correct mismatched names.
Re: Should we get rid of style insensitivity?
To me it seems clear that regular users generally prefer it the way it is. However I do not believe dom96 would make this post if he were not getting consistent feedback about this front potential adopters. I believe that signal should not be ignored. If the feature isn't being removed maybe it should be considered for some slight modification in terms of usage or documentation. Also I believe this is a microcosm of the larger challenge of user adoption and the boots-on-the ground recruitment process. One thought is that since I believe people want things that are familiar or popular and don't want things that are unfamiliar, if there were some way to make case insensitivity a cool new programming thing rather than just weird, that could change the feature into an asset for recruitment. Not that that would be easy to do. But if someone who was popular and had a reputation as a programming guru made a post about why case insensitivity is the new better way to go and that was well received, that would be a thing. In my opinion people will follow a trend subconsciously and then rationalize all the logical reasons they did it without knowing that they were actually just following a trend.
Re: Should we get rid of style insensitivity?
I think that changing Nim to get more users is exactly what should not be done.
A language should not be adapted to suit the opinion of a majority of potential
users. Rather users have to learn other ways to work.
For me, many of those who definitively rejected Nim for its case insensivity
will have, anyway, rejected Nim for other reasons: the fact that it is not
object oriented, its GC, the exceptions, its syntax, usage of keywords rather
than symbols ("and" rather than "&"), etc.
And I don’t buy the idea that there are lot of users who would prefer case
insensitivity. Those who are satisfied with the current situation do not say
anything. They use Nim, that’s all. It’s easier to find people who complain
than people who agree.
Look at other languages. Go, for instance, has chosen to use return codes
rather than exceptions. This is an important choice, much more important than
case sensitivity/insensitivity. A lot of people have complained. It was their
right, but Go designers have not changed anything. They have lost potential
users, me for instance, but have considered that a language should follow a
philosophy. That’s fine an I respect this.
Python is another example. When it was a young language, its syntactic
significant indentation has been a blocking point for a lot of users. At this
moment, Guido van Rossum could have get a lot of users by changing this. He
don’t. Slowly, the language has received more and more attention, until even
the most reluctant have finally learned it. For me, Python is the exact example
of what should be done: no concessions for major points. Whether case
sensitivity/insensitivity is a major point is somewhat disputable though.
Re: Should we get rid of style insensitivity?
There's a difference between having style insensitivity and writing/editing code (either manually or by a tool) to let you write your code in different styles. You could also write a tool to achieve this in C or use define statements and the like to do the same thing.
Re: Should we get rid of style insensitivity?
> many of those who definitively rejected Nim for its case insensivity will > have, anyway, rejected Nim for other reasons Stating that the same group of people dislike style insensitivity, GC, etc is a bold claim.
Re: Should we get rid of style insensitivity?
> Stating that the same group of people dislike style insensitivity, GC, etc is > a bold claim. That’s not what I meant. I suppose I should have been more precise :-). What I mean is that some people will find any reason to reject a language they don’t like. And why do they not like this language? Simply, because it isn’t their favorite language and all that’s different is bad. Programming languages have always been a very controversial topic. For me there is a big difference between people who don’t like the case insensitivity in Nim, but use the language, and those who pretend that they will use Nim if it was case sensitive. Nim has a lot of attracting features and I don’t believe that case insensitivity could prevent to use it. There are so much more important things. In fact, anything which is somewhat new has always been criticized. A new feature is a differentiation factor and, so, it must be fought. Python has, for a long time, criticized for its syntax, which truly is a differentiation factor. Guido van Rossum has not changed anything and he was right. Now, languages with a syntactically significant indentation as Nim is, are accepted. And, for me, this is an important feature (but, again, not one that could prevent me to use languages with traditional syntax).
Re: Should we get rid of style insensitivity?
Case insensitivity is one thing, style insensitivity is another, and what Nim does is yet another thing. You probably know this but just for the sake of removing any possibility for misunderstandings for others: * Case insensitivity: `fooBar` == `foobar` * Style insensitivity: `foo_Bar` == `foobar` * Nim's style insensitivity: `foo_Bar` == `foobar`, but `F` != `f`
Re: Should we get rid of style insensitivity?
I’d like a vote. I completely see where Dom is coming from with this proposal. This is mentioned as a negative in every discussion about been that I’ve seen in reddit and proggit I’m sure there are people who would give Nim a chance but which are very put off by this. Personally I am not against this in principle, and I can understand some of the proposed benefits. I haven’t needed it myself and I prefer to be consistent when I write code but I imagine it could be useful when interfacing with external libraries and with non nim code for example. However I believe that people in favor of it minimize the drawbacks a bit. For example the fact that it makes identifiers harder to find is a real problem. I don’t think that saying that you should use ningrep to search is a good answer. People like to use their existing tools such as their editor of choice’s search box and won’t happily change that just to use a new language. I think we can keep the benefits of this controversial feature without most of its drawbacks. To me the biggest problem is that it is enabled by default, for all the code in all the files. Instead I’d suggest making it optional and letting the user explicitly enable the style insensitivity on a particular section of the code or for a particular library, etc. I believe someone else proposed something similar earlier in the thread.
Re: Should we get rid of style insensitivity?
We can turn it anyway we like but we must not go against the vital rule that a compiler must not ever change an identifier behind the developers back. leading '_' can be discussed (I'm pro but can accept Nim staying against it). Case sensitivity and/or rules (like types capital 1st. letter, vars and procs not) can be discussed/voted on/dictated by Araq, One might not like the outcome but one can live with it. "Style insensitivity", however, goes against the vital rule. Simple as that. Even a "religious" preference like CamelCase over snake_case is something that one may live with if that preference would be important enough to @Araq and the core team to ban underscores. But the "style insensitivity" was a major sin from the start. Period. If Araq hates snake_case so much he should simply forbid it (i.e. any underscores in any identifiers). But allowing them and even dressing it up as "liberal" and cool feature - but then having the compiler change identifiers and un-snake_case them is a major sin and frankly not acceptable for a good language that is concerned with safety and clarity - even more so when a language produces code in other languages. If I wanted to play lottery with the compiler I could have stayed with C.
Re: Should we get rid of style insensitivity?
Just because code has uniform _naming-style_ doesn't make it easier to read, and vice-versa. By non-programmer point-of-view, glorious_function and gloriusFunction is (about) same, read same, and (almost) look same, and that's only natural.
Re: Should we get rid of style insensitivity?
Thanks for the precision. But is it really style insensitivity? That’s what I thought until I understood that it is only a consequence of ignoring the underscores in identifiers as underscores are ignored in numbers. So Nim style insensitivity may be seen only a consequence of Nim case insensitivity and of its special usage of underscores to improve readability in numbers and identifiers. Still, one can dislike it, but it’s not so arbitrary that it might seem.
Re: Should we get rid of style insensitivity?
I think a vote would be fine. Ballot box stuffing is possible, but probably
identifiable via sheer numbers since the Nim community is so small unless the
vote gets HackerNews'd or Slashdotted. I also agree that the people who matter
most would never participate in such a vote because they've already dismissed
Nim for being "too creative" on the identifier front.
Wording matters a lot, too, as in any survey. I'd wager that there would be
almost zero "yes" answers to a "would you stop using Nim if it became fully
sensitive?" question. Also, a "do you know at least one developer who never
tried Nim because one of the first things they heard about was its 'weird'
ident rules?" would probably get an average of >50% yes's. Developers in very
niche internet languages are not always the most social creatures or my
estimate would be higher.
Personally, I like identifier _sensitivity_. I think things that look different
to a person should be treated as different by the system, especially a system
used by programmers who know one wrong character somewhere breaks a program.
Ease of use studies about filesystems by non-programmers are at best weakly
relevant - and anyway often there is a wrinkle of "creation time casing" and a
"reference time casing". Studies in text also show using ALL CAPS ALL THE TIME
makes characters most easy to distinguish, but programmers tend to not want to
do that.
In physics and math (where the underlying syntax of adjacency implies
multiplication) single character variable names like F=ma and subscripting
prevail. The handwritten/specialty script nature of those fields then pushes
users to use _more fonts_ and italics and bold face and so on, and you often
see textbook authors declare their style conventions. In general, more terse
languages without a lot of syntactic noise (like Nim) benefit more from shorter
identifiers which in turn benefit more from sensitivity. Speaking in voice
about "cap A" is as easy as "A zero".
Giving more picky people flexibility to define their own conventions seems good
to me, and to me that means sensitivity not the current rules. Less picky or
more overall consistency-oriented people will just go with the flow and imitate
Nim standard library conventions. Many will always go for camelCase since they
know they'll have a lot of stdlib calls and the stdlib does that and so they'll
want their own code to match that "larger world convention". C programmers
imitating C stdlib and Java the Java APIs and C++ or POSIX programmers the
POSIX apis and so on drive all this enormously. So, the core Nim community can
probably get most of what they want just by controlling the style used by the
stdlib.
Also, one has to pick which battles one fights! _Injudicious_ choice of
characters will _always_ be a problem. In typical fonts for Latin script
languages the upper- and lowercase versions of a letter "visually collide" for
about 50% of the 26 letters. For another 50% there is a lot of visual
ambiguity, like the similarity of O/0, 1/l { big-Oh vs zero and one vs
lowercase-ell }. Colon and semi-colon, commas and periods are often really hard
to see much difference in but make the world of difference. To my knowledge, no
one suggests in any seriousness that Nim should forbid big-Oh or little-ell
from identifiers or that writing Nim should require a certain font because
otherwise it's hard to tell what means what. Sometimes you have to just rely on
users of any language to not choose to write deliberately confusing things or
use programming-hostile fonts.
However, it is perfectly fine ( _fantastic_ , even!) if the compiler has one or
several warning systems (that can be easily turned off by a flag) for _ALL
SORTS_ of confusing scenarios that "encourage" clarity/simplicity. People "in
the thick of it" can have the warning be active. People more in their own
closed world or with habits/inclinations/fonts that make certain mistakes less
likely can turn it off. Problem solved. Besides naming convention issues,
uneven spacing around operators is a good example. There's a warning for that
in place now. Another example without a current warning in place would be
spaces of leading indentation -- 1 spaces vs 2 vs 3 vs 4 vs 8 -- all currently
treated the same by Nim. A shift from indents of 1 to 8 is probably some kind
of bug or at least a highly erratic formatting style. The compiler warning
could even take some limit where a change of indent shift by <=N was ok and
warn only for changes bigger than that.
Re: Should we get rid of style insensitivity?
Here is a little experiment. 1. Write a sample code, explicitly use style insensitive in the code 2. Show it to some colleagues who doesn't know nim 3. Try to explain to them the code without bringing style insensitive up unless they ask 4. They will definitely ask why you have get_data() and getData() 5. Explain to them how it doesn't matter 6. Take their opinion on that You will not have a problem explaining the code to them since nim is so concise and expressive, and I'm sure they will love it. Now, colleagues read each other code all the time, so maybe instead of asking ourselves if we like style insensitivity, we should ask if those whom we work with would welcome it into our production pipeline, and wouldn't mind adopting nim in a team project. I'll keep using Nim, regardless of the result of this discussion, and I'm looking forward to replace Go completely with Nim (and/or Zig) in the future, but one of many things I appreciate in Go is code consistency, and how I can read code I wrote years ago, and still understand why I wrote it, and what each part means.
Re: Should we get rid of style insensitivity?
@allochi that experiment does not really make much sense, because you are not supposed to use style insensitivity to mix styles inside a codebase, unless you are masochistic. Style insensitivity is used to take a library written in a different style and use inside your project without having to adapt to the library style
Re: Should we get rid of style insensitivity?
Side note: Adapting to a libraries style _can_ also been as an advantage
("Obviously code from elsewhere").
In fact, almost all of those questions _can_ be seen this or that way.
Based on some decades experience I can't remember having felt that some
libraries naming convention was problematic for me.
If we want freedom - and I guess close to 100% want freedom - then diverse
styles are a price we shouldn't be too concerned about.
What is beyond personal taste and styles, however, is that whatever (in terms
of style) we write, a compiler should never ever change it behind our back. The
compiler may complain, say about a leading underscore, if a language doesn't
allow it but it must change anything.
Btw. I know the underscore already as (typ.) "digit triples separator" from Ada
and love it. But those are (numerical) literals and not identifiers and
"changing" those '_' (ignoring them) in literals is OK and a different matter.
Btw.2 My own experience with non/not yet Nim users is that they find style
insensitivity exotic, weird, and sometimes funny. I've yet to see a colleague
to _like_ it and to consider it as advantageous (for the sake of fairness: my
group probably does not represent the general developer community)
Re: Should we get rid of style insensitivity?
Does anyone out there routinely use this feature of diverging from the style of an `import` or as I mentioned just follow the lib's conventions? Part of @dom96's survey should perhaps ask if that aspect is just a "theoretical nicety". I mean, someone cared enough about project-internal style consistency to write NEP1 and someone also cared enough to add that `nim c --nep1` system. I think if most/all example code/standard and popular libraries use one style that most people will copy it. The reasons they would _not_ imitate it are more likely to be either A) technical like wrapping sensitive libs or B) cultural like some corporate style guide legislation (of which idents are just one dimension with spacing, comments, function size, etc. being many others) or C) strong personal preferences. In those cases, they seem more likely to just reject Nim outright, but that's just my hunch. C) could cut either way. So, call it 5 out of 6 cases of rejection for 1 case of ecstatic acceptance. A 6x larger community would make a world of difference... So, if it's the primary motivation is just that Nim core personally does not want to deal with other identifier styles, I doubt there is much value realized by style insensitivity. In a fully sensitive world they might have to deal with it 5-10% of the time. Yeah, more than zero. It's hard to know for sure and definitely late in the game, of course. It's certainly unique. Maybe it's the killer feature! If it were _easy_ to predict popularity then the world would be a _very_ different place.
Re: Should we get rid of style insensitivity?
> you are not supposed to use style insensitivity to mix styles inside a > codebase If that was the case, and I wish it was, style insensitivity would at least be limited to the `import`, `importcpp` and `importc` statements to be resolved with symbol binding.
Re: Should we get rid of style insensitivity?
> Does anyone out there routinely use this feature of diverging from the style > of an import or as I mentioned just follow the lib's conventions? I do. I do not feel it to be problematic how the Nim lib naming is but I always and consistently use my own style in my own code (CamelCase for vars, snake_case for procs). I'd probably also use my own style for types but Nim's rule for types (capital 1st. letter and CamelCase) matches mine anyway. And yes, not being able to keep my own style (that I thought about and deliberately chose) would have kept me away from Nim. And I absolutely HATE Nims style insensibility; so much so, in fact, that I find myself less disinterested in e.g. Zig than I'd like to.
Re: Should we get rid of style insensitivity?
One person wouldn't use multiple styles, a big team of developers, it's different story. Imagine in real big project, when you hire consultants to work on part of a project, and they write their code in a different style than that of the team, which they are using for months, and then you need to debug that code - I have been there multiple times with my consultants, mistakes happen out of habits. @araq and @dom96, maybe a tool would solve the problem, like an option in fmt that says reformat all identifiers into a certain style, this way code can be imported and transformed into one single style. One problem with my suggestion. It's easy to convert between camel case myVar and snake case my_var, but not when it's not obvious myvar, since these all are the same variable. The funny part, I saw the vote on twitter, and by mistake voted "Yay" XD
Re: Should we get rid of style insensitivity?
@gemath Actually, a pure Nim library could not respect NEP1 and follow a different naming style. If I use such library, I will call it using NEP1 identifiers - no importc in sight. I think it could make sense to add a warning in the compiler for the case where mixed styles are used **inside** the same project (that is, not in code coming from nimble libraries)
Re: Should we get rid of style insensitivity?
Completely agree. If that is the main benefit, why not focus on giving a non controversial solution to that particular problem?
Re: Should we get rid of style insensitivity?
Although I do not use Nim everyday (I'd like to!) - I've found that the style insensitivity is by far the biggest obstacle I've found in Nim adoption at my company. I think it might be easier to overlook if there was a tool that could that could format the code in one way or another, or a linter of sorts that would enforce a particular style?
Re: Should we get rid of style insensitivity?
When people say it's an obstacle for adoption, exactly in what way? Do you mean that they actually tried to compile something, and it failed because of identifiers being considered the same in Nim? Or just that they looked at the web page, saw that and that is the thing they decided to use as the reason they we're giving? Because in the first case, it seems it would be better to differentiate the identifiers with say one more deacriptive, and in the second case they may just not want to learn a new language anyway but didn't want to say that. However if it is the first case and they couls not change the codebase because it was too many other identifiers or something, I'd that occurs frequently it could be a case for making it optional. But we would need to confirm that they actually tried and had a practical issue that wasn't better resolved with just making identifiers more specific.
Re: Should we get rid of style insensitivity?
The reason the C sometimes relied upon underscores at one time was because in the good old days many system only supported one case. Now that all modern systems have upper and lower case, it makes sense to use an initial uppercase letter to use the same descriptive for a type rather than variable.
Re: Should we get rid of style insensitivity?
> I've found that the style insensitivity is by far the biggest obstacle I've > found in Nim adoption at my company. I can definitely say it's incorrect finding. 99% companies like to play safe, use whatever popular without really understand pros/cons of what they're using. Because they don't want a super good programmer but a bunch of mediocre programmers, so they can replace programmer whenever they want. It's not about style/case-insensitivity, but rather how popular it is. So it's back to a **killer app** , if someone produces killer-app using Nim, the popularity should skyrocket and whatever the wart, whether they like it or not, they will use it (see JavaScript)
Re: Should we get rid of style insensitivity?
> I think it might be easier to overlook if there was a tool that could that > could format the code in one way or another, or a linter of sorts that would > enforce a particular style? `--styleCheck:hint` or `--styleCheck:error` can be passed to the compiler which enforces that all symbols in a project uses camel case.
Re: Should we get rid of style insensitivity?
@runvnc "It's almost like there is an IQ test built into the language." This has nothing to do with IQ, this is not fullblown monads or something, it's a thing that people expect to be very simple and obvious and it isn't. (they might be wrong, but don't make wrong conclusions)
Re: Should we get rid of style insensitivity?
I guess a language- and compiler recommended style guide that a lot of people follow increases the value of the eco-system as a whole - just like a single developer is likely to output similar code and benefit from the familiarity that this brings, a whole community come together and do so, decreasing needless friction between libraries and making it more pleasant to use code from multiple sources. Thus, a system that's good for the community is one that guides the novice towards a safe and globally beneficial defaults, while it allows the master the freedom to step outside those bounds so as not to become a constraint. Seen through this lens, the case insensitivity feature does not really have to be removed - it simply can be hidden behind an option that allows you to turn it on when appropriate.
Re: Should we get rid of style insensitivity?
Well said, @arnetheduck. Honestly, for the true master, you could do some pluggable system that allowed macro/compile-time proc-driven identifier transformation with the current rules as a simple activation maybe as a pragma on `import`. Then people could override that current "compromise" batch of ident rules with something even more idiosyncratic (e.g., that handled ALL_CAPS or maybe CAPPREFIX_Foo identifiers differently, as needed/wanted). You might need to declare a convention inside defining modules, too, though, if you depart from the default. Anyway, instead of quashing admittedly often time-waste-y arguments about (just some dimensions) of style with a totally unique set of ident rules (more than just "case insensitive" as @dom96 points out), give devs tools to manage disagreements.
Re: Should we get rid of style insensitivity?
Sorry if I didn't give enough context... I think its mostly they had a knee jerk reaction and didn't choose to understand it completely. Definitely not that they tried to compile something and found it problematic. I was giving an hour long talk at my workplace to our engineering department (mixed bag of C++, Go, Python, JS developers) about using nim's language features and potential uses. I did bring up the style insensitivity at one point, and just saw the reaction from different individuals. Also just having conversations with people, I've found that can sometimes turn people off from exploring more. If they're really interested, I think they might come around (or agree that its not such a big deal). To some developers, I pointed them to the wiki page on it, but I think they just inherently found it confusing. And the fact that it does require an explanation (albeit short) does speak that it add _[some](https://forum.nim-lang.org/postActivity.xml#some) complexity. Re @alehander42 's point - > it's a thing that people expect to be very simple and obvious and it isn't To be clear, I personally think it's a neat feature :) re: @GULPF I didnt know about --styleCheck - Thanks!
Re: Should we get rid of style insensitivity?
@dom96 * Case insensitivity: `fooBar == foobar` * Style insensitivity: `foo_Bar == foobar` * Nim's style insensitivity: `foo_Bar == foobar`, but `F != f` I will only add my experience regarding the above distinction between the 2nd and 3rd point. There have been at least three occasions where I came back to programming in Nim after a week or so and always get bitten by the same mistake: * Right, I don't have to care about underscores and case, * hack, hack, hack, * compile, * What do you mean: undeclared identifier: 'quitsuccess' !!! * Ohh, right! the first character is case sensitive, it's 'QuitSuccess'!, * But 'Quitsuccess' is even uglier! * Then comes the realization that Nim is not really style insensitive... Sigh. My wish would be that we would pick between either the 1st or 2nd point.
Re: Should we get rid of style insensitivity?
**I don 't want a vote**, but I want more rationalization behind the feature. I like the feature, but I can see that a lot of people are afraid of its effects in corner cases. The article should explicitly tell that style insensitivity is rarely used and state the cases when it should be. In fact, I've stared writing it up, but never got to finish it :-)
Re: Should we get rid of style insensitivity?
Can someone help me: In which places in the source code of Nim do changes have to be made to get rid of case sensitivity of the first character? I have found compiler/idents.nim proc cmpIgnoreStyle, but changing only that procedure does nothing it seems. P.S.: This is only for my personal build on Nim, I do not want to force this behavior on anyone.
Re: Should we get rid of style insensitivity?
remove any instance of strutils.normalize ? cmiiiw
Re: Should we get rid of style insensitivity?
@mashingan Thanks, will try it today!
Re: Should we get rid of style insensitivity?
My bad, I didn't carefully read what you wanted, I was under impression you want remove style-insensitivity altogether. Yeah, you should use normalize instead of removing it, but I never tried it so you need to test it yourself.
Re: Should we get rid of style insensitivity?
I'd prefer this not change so close to v1.0 I feel the rationale of case insensitivity is sound. It reduces errors, it forces us to use distinct identifiers. On the other hand, we should go whole hog and make the first letter insensitive to style/case too. I think this last point should be a vote, given it may break tons of stuff.
Re: Should we get rid of style insensitivity?
@preempalver It used to be the case that the first letter was also insensitive. That was changed because many people - me included - like to do something like let person: Person = ... Run
Re: Should we get rid of style insensitivity?
A quick search found that `compiler/idents.nim` proc `cmpIgnoreStyle` and `lib/core/macros.nim` proc `cmpIgnoreStyle` are the only ones that compare the first character via `if a[0] != b[0]: ...`, but commenting that out doesn't seem to do anything. Any other suggestions of how to remove the case sensitivity of the first character?
Re: Should we get rid of style insensitivity?
Ah, I assumed something like this was the case, mostly cause I come from Java where the line `Person person = new Person():` is common, but I feel that is always a nomenclature failure (where the variable name should be "processedPerson" or ''beingEnrolled" or something.
Re: Should we get rid of style insensitivity?
The first letter sensitivity can be used in proc arguments too, to save time.
