4 ms·

In a perfect world, yes. But having worked with Python I must say not all Python libraries are PEP 8, and I've more than once ended up with a strange mix of sty

by PMunch 8y ago

In a perfect world, yes. But having worked with Python I must say not all Python libraries are PEP 8, and I've more than once ended up with a strange mix of styles. 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.

dom96 8y ago
Something else to keep in mind is that Nim also has it's own version of gofmt in development, it's called nimpretty. 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.
mikepurvis 8y ago
Prior to Py3, not even the entire _standard library_ was PEP8: https://docs.python.org/2/library/queue.html https://docs.python.org/2/library/queue.html Before 2.6, the situation was even worse, with camel-case methods in the threading module: https://docs.python.org/2/library/threading.html https://docs.python.org/2/library/threading.html
dymk 8y ago
Even if somebody deviates from a style guide, the library is still usable. The consumer might just need to use a casing convention they're not using elsewhere. 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.
- beagle3 8y ago
  Nim's roots are firmly in Pascal and Ada, which are both case insensitive; Every editor supports case insensitive search so I don't understand what your problem is with case insensitive identifiers. "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
- PMunch 8y ago
  I find it a big nuisance to use different casings in my code, but obviously people are different. Most of the type you won't be using the style insensitivity though, so for the most part a simple case-sensitive search will give you exactly what you are expecting. For more complicated things though you have nimgrep, and also nimsuggest (and soon nimlsp) which gives you editor support for finding and renaming identifiers. It really is a much smaller issue than people think it is.

by PMunch 8y ago

dom96 8y ago

Something else to keep in mind is that Nim also has it's own version of gofmt in development, it's called nimpretty. 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.

mikepurvis 8y ago

Prior to Py3, not even the entire _standard library_ was PEP8: https://docs.python.org/2/library/queue.html https://docs.python.org/2/library/queue.html Before 2.6, the situation was even worse, with camel-case methods in the threading module: https://docs.python.org/2/library/threading.html https://docs.python.org/2/library/threading.html

dymk 8y ago

Even if somebody deviates from a style guide, the library is still usable. The consumer might just need to use a casing convention they're not using elsewhere. 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.

beagle3 8y ago
Nim's roots are firmly in Pascal and Ada, which are both case insensitive; Every editor supports case insensitive search so I don't understand what your problem is with case insensitive identifiers. "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
PMunch 8y ago
I find it a big nuisance to use different casings in my code, but obviously people are different. Most of the type you won't be using the style insensitivity though, so for the most part a simple case-sensitive search will give you exactly what you are expecting. For more complicated things though you have nimgrep, and also nimsuggest (and soon nimlsp) which gives you editor support for finding and renaming identifiers. It really is a much smaller issue than people think it is.