I feel like this is mentioned (by the people who just glance over Nim) every time there is some discussion about Nim, and IMO it is blown way out of proportion.
In my cca year and half of using Nim, I not even once had a problem with the style insensitivity.
IMO, you (general you) shouldn't use `my_foo` and `myFoo` for different things, regardless if a language allows for it or not.
Not hard to make up any number of examples where spacing or capitalization matter for good reason. They matter to humans; its just silly to make them not matter to the compiler.
Now back to your concern of identifiers being read in different ways meaning different things. Once you know that this will be an issue you tend to think about it when naming your variables, and so it tends to not really be an issue. The thing is that once you get used to it you know that `pidTarget` and `pIdTarget` is the same thing, so you either relax you expectations, or you don't construct your names with this ambiguity. And besides, a "pointer to a target id" and a "scalar process id" probably don't share the same type, so the compiler should be catching that anyways if you ever used it wrong.
grep -i solves the case issue, and grep/ripgrep probably _should_ have a feature to ignore _ ; in which case you will be able to use them - but until then, nimgrep will do that work.
I don’t know how atheistic style looks, but Nim is style agnostic - everyone can practice their religion and they all get along. C, Python, and the real world - not so much.
This one point is always worth considering when deciding on user-facing portions of technology.
Not to mention, in my opinion it's more aesthetically pleasing, but that's just me :)
(let ((|hello world| 3)
(|HELLO world| 4)
(|こんにちは (jp)| 5)
(|pi\|pe| 'piped)
(|newlines
work
too| 6))
(list |hello world| |HELLO world|
|こんにちは (jp)| |pi\|pe|
|newlines
work
too|))
; --> (3 4 5 PIPED 6)Search HN (box at bottom of page) for Perl6 and you will find many articles with references to kebab-case.
As mhd said, it's used in Lisp too.
But is not a deal breaker for me. If the language doesn't let me I can use `ii` or `i2` or whatever.
Please notice that the first letter in Nim is case-sensitive, so `I` != `i`, and you can continue use your conventions.
And before some new comment starts bashing that, I think this is a must so you can differentiate your types, written in PascalCase, from your variables, written in camelCase.
I did not know this about Nim and does also seem quite a big turn off and a bit of a WTF decision
I have never coded any Nim, just read about it though :)
I guess the intention is NOT to let you carelessly use Myvar, MyVar and myvar willy-nilly in your code, as I had first imagined
I assume the intention is to PREVENT you from deliberately defining those names as different vars, which would be confusing
So, on reflection, maybe it is not such a WTF
int main() {
int myVar = 1;
int my_var = 2;
int mYVAR = 3;
int myVAR = 4;
// ...
}
It saved me few bugs already.
I would love to find a language for game / engine development that's as performant as C++ and as easy to use as C# or Python, but this issue scares me. If I search for a variable using any of my existing plain text search tools, I expect to find the variable. It makes me think that this isn't a language that's meant to be used by large teams on large, long-lived codebases.
I think you are over-estimating how inconsistent Nim code typically is. I have been coding in Nim for a very long time and I personally just use case insensitive search (which I use for all languages anyway).
It's easy to tell from context what the identifier will be. If the code base is snake_case then I search for `foo_bar` if not then I search for `fooBar`. I cannot remember a single time this has failed me, and even if it does then the worst case is you'll need to search for the other alternative. There is really no trouble here and I feel like a lot of people, when they see this feature, worry too much because it's so different. Please please please reconsider, I know it's a strange feature and it doesn't feel worth it, but it really isn't a problem at all.
But mostly, it just seems like a really weird call to make for the language. There are real disadvantages to it -- I can't really rely on my search tools. So that... when you're using a library you can refer to its identifiers using a different capitalization convention if you want to--why is that important?
I don't know, it just seems like a really weird call to make, and if that's one of the first things I've learned about the language it makes me think there are probably plenty of other weird things like it.
But why? I personally haven't experienced this having worked in a big Nim project. I'm really curious why you think a bigger project could become burdened by this.
> There are real disadvantages to it -- I can't really rely on my search tools.
I disagree. You can rely on your search tools, as I've demonstrated in my previous reply. I feel like you're thinking of the worst case scenario and convincing yourself that it's very common. It simply isn't, people don't create crazy identifiers, why would they?
> So that... when you're using a library you can refer to its identifiers using a different capitalization convention if you want to--why is that important?
It's important for consistencies sake. In the real world developers prefer different conventions, so you undoubtedly run into a library which uses a convention that is different to your own. It's nice to be able to call that libraries functions in the same convention as your own.
I agree that it's not a huge advantage, which is why I created this thread on the Nim forum recently: https://forum.nim-lang.org/t/4388. My main reason to consider getting rid of it though is people like yourself who dismiss the whole language because of this small feature :(
It has a lot in common with Nim, but is backed by a much larger community. Its FFI interface for C functions is faster than...C.
If Julia doesn't fit your use case(s), Rust might also be worth a look. What worries me about Rust is that it looks to me to have an awful lot of boilerplate that detracts from readability.
If you had your own preference one way or the other, you could call a library's `snake_case(foo)` function as `snakeCase(foo)` instead, and pretend that the library matched your own personal style.
Of course, this isn't very useful in practice, and makes simple things like grepping for identifiers or Googling a function that much harder. Tools for refactoring also suffer.
What's better is having a single style guide enforced by ordained tooling; e.g. PEP 8 for Python, Prettier for JavaScript, or gofmt for Go.
Nim on the other hand takes a different approach, don't trust anyone else to keep things the way you like it, but rather allow you to use it however you want. This means that if some inexperienced Nim programmer who didn't care to look at the NEP 1 style guide (yes Nim also has a style guide, which says Nim prefers camelCase), but nonetheless wrote an interesting library could still see his library used by others.
If everyone is using this tool anyway then style insensitivity will not be a problem, and for those cases where some library uses snake_case instead the code formatter will still be able to format your code completely consistently even if you're using that library. There is no way that gofmt or any other language's code formatter can do that.
This is such an incredibly small inconvenience, I have no idea why the Nim language would choose to make identifiers case/_ insensitive. Basic refactoring tools become unnecessarily more complicated.
Just searching for an identifier is a complex regex instead of what should just be ctrl+f.
"Basic refactoring tools" would just need to replace the case sensitive search with insensitive. Every editor knows how to do that.
If you're talking about the underscore and first letter rules - yes, they're different, and that's why nim includes nimgrep, and support was added for just about every editor under the sun already (Emacs, VSCode, Vim, Sublime, TextMate at the very least). It's still Ctrl+F
https://docs.python.org/2/library/queue.html
Before 2.6, the situation was even worse, with camel-case methods in the threading module:
That's something that would have appealed to me years ago, but now not so much.
In 2018, I want all the libraries, and all the code I ever look at in a language to follow the same style and naming conventions. If you adapt yourself to that, my belief is that will aid comprehension in the long term.
So I appreciate the language communities which have strong conventions which are followed by the majority, and are encouraged / enforced by the tooling. All hail gofmt and rustfmt!
It's way too easy to ignore (or even embrace) the identifier equality rules in Nim to make this the hill you die on. My story's very similar to other responses - I've been using Nim for quite a while and these identifier rules have never been an issue.
I strongly suggest anyone hung up on this monster under the bed try Nim anyway as it's really pleasant to use. It's sad that all Nim's benefits are sometimes drowned by mostly unfounded hangups on this identifier thing.
Anyway, don't worry: I didn't die on that hill. I've had the opportunity to spend some more time on Nim since.
There was a set amount of time available to spend on Nim at that point, and all that time went into finding out why nimgrep exists in the first place, then reading up on the background.
It didn't help that all nimgrep's documentation had to say on the matter was "Nimgrep has particularly good support for Nim's eccentric style insensitivity", which doesn't really tell you anything unless you already know about Nim's style insensitivity.
I've seen people write wrappers just to fix casing.
EDIT: you can still change them in importc pragmas, but this still seems less nice to me.
Still, you can reuse Nim libs even if they don't follow nep1: one can still use nimpretty/gofmt for his own codebase.
Using name completion in my editor is enough to keep the naming consistent. Try the language for a month before deciding.
Also, the survey indicates that very few people are turned off by this feature:
https://nim-lang.org/blog/2018/10/27/community-survey-result...
Basically, Nim ignores case (except for the first character) and underscores in identifier names, so the following is a valid Nim program and all those names refer to the same variable:
Most people wouldn't actually write code like that, but I personally found it to be a turn-off.More on this: https://nim-lang.org/docs/manual.html#lexical-analysis-ident...