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
Why should they? Nim _has_ a good - and minimally restricting - rule. Types
start with a capital letter, vars and procs don't. There's nothing in your way
to, e.g. have all types start with 'T' (like Tperson or TPerson)
Constraining types and variables to have different namespaces would be a
solution. The only issue with that is that sometimes types can be used as
values (typedesc) and in that case there could be a clash (unlikely, but still).
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.
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?
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
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
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
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:
The first letter sensitivity can be used in proc arguments too, to save time.
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.
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
@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
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
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.
@mashingan Thanks, will try it today!
remove any instance of strutils.normalize ? cmiiiw
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
**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
@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
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
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"
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,
@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)
> 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
> 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
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
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
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
Completely agree. If that is the main benefit, why not focus on giving a non
controversial solution to that particular problem?
@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**
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
> 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
> 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.
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
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
@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
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
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
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
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.
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,
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
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` ==
> 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
> 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.
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.
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
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
**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
> PS: Can we not edit our own posts?
You can, don't you see a pencil button on your post?
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
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
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
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
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,
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
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
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
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
"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
I think a vote is good, will be voting no for the change though
Let's then remove _ as a digit separator because of grep.
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.
And that's why there is a nimgrep.
> 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%
@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.
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
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.
> 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
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.**
> 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
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
@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).
@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
@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
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
> @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
> 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
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
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
> 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
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
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
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
**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 ?
**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
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
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
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
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
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.
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
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
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
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
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
> [...] 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
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
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
1 - 100 of 106 matches
Mail list logo
