5 ms·

The idea that thisFunction and this_function are the same might be worse than the problem they're trying to solve. I cannot unfortunately have experience with l

The idea that thisFunction and this_function are the same might be worse than the problem they're trying to solve. I cannot unfortunately have experience with larg-ish codebases in nim to tell if this would result in an actual problem or not, but the idea that I have to scan between two possible identifiers in the code can be a source of stupid bugs in the same vein as case-insensitive identifiers. On the other hand I can definitely see the appeal of it (some python packages go against the recommendation and sort-of taint the style of other sources). This so far was the only "weird" comment I could think of.

gjm11 12y ago
That seems like a really bad idea. It means that searching for an identifier requires you to allow for the possibility that there might be any number of underscores inserted anywhere. I suppose in practice you'll rely on the fact that no one will be inserting them other than at word boundaries, but it still seems horrible. (I'd worry about ambiguities of the experts exchange / expert sex change type, too, but my guess is that they're extremely rare and usually either harmless or instantly caught by the compiler. Still, the mere possibility makes me twitchy.)
- gfasdgsfd 12y ago
  I'm personally not too happy about this, but there are restrictions on the use of underscores: - You cannot have two underscores in a row - You cannot have a leading underscore
  - deleted 12y ago
    [deleted]
- def- 12y ago
  I would consider it bad style to abuse the case-insensitivity like that. It can be used for good too, for example if you have a bunch of different naming conventions in the libraries you use: proc some_lib_function(x: int) = echo "hi ", x proc anotherLibFunction(x: int) = echo "hi ", x proc crAzY_LIB_WRITERS(x: int) = echo "hi ", x Then you can still call them consistently: someLibFunction(10) anotherLibFunction(11) crazyLibWriters(12)
- ebiester 12y ago
  Certainly, I would have some sort of lint to enforce naming conventions. I don't like it at all. Searching for a function becomes a nightmare.
  - EXetoC 12y ago
    Is it not good enough to have specific grep tools? nimgrep for example, and there are procs for working with this IIRC.
    - def- 12y ago
      I prefer to have a consistent code base, then I can use the internal tools of my editor, which are not aware of Nim's identifier rules.
  - zahary 12y ago
    The Nim compiler offers a set of tools intended for use in IDEs ant text-editors that help with this. Besides the style insensitive grep, there are also a compiler-assisted "go to definition" and "list references" commands.
- zak_mc_kracken 12y ago
  Maybe you're thinking in terms of a text editor and not an IDE? With an IDE, you look for symbol references, not text with regexps. You could imagine that the IDE's search would be smart enough to know that if you look for foo_bar, it should also report occurrences of fooBar. Either way, I still find the idea a bit weird. If the language wants to be opinionated about naming, maybe it could simply make _ illegal in an identifier or, to push it one level further, refuse to compile any identifier that is not camelCase.
  - gjm11 12y ago
    I was thinking of both. An IDE is worse unless it's actually targetted specifically at Nim, because its code for finding symbol references surely won't know about Nim's underscore-blindness. (But I'm not much of an IDE-user myself. Perhaps modern IDEs have enough hooks that you really can control this stuff?)
- DAddYE 12y ago
  The reason of this (while I agree with you) is because Nim comes with a strong interop with C/C++ so the problem is that in C and C++ there is a SnakeCase debate still open. They did that so your program can invoke c (or even nim libs) without taking care of the upcase/underscore style and use your own. While this seems problematic they added some neat features to avoid problems with `uniqueness` of the name and so on. One thing I wish at this point is to force the compiler to stop if this pattern is not uniform within a codebase.
Lrigikithumer 12y ago
I'm pretty sure that was removed, the case insensitivity.
kevin_thibedeau 12y ago
Case-insensitivity is not that much of an issue in static languages. It eliminates the burden of having to remember the Studly-Camel-Lumpy-style-du-jour. Accidental name clashes will be caught at compile time. Nim's hybrid approach is more adventurous but I can only see it being a problem with reusing symbols from other case-sensitive languages.

gjm11 12y ago

That seems like a really bad idea. It means that searching for an identifier requires you to allow for the possibility that there might be any number of underscores inserted anywhere. I suppose in practice you'll rely on the fact that no one will be inserting them other than at word boundaries, but it still seems horrible. (I'd worry about ambiguities of the experts exchange / expert sex change type, too, but my guess is that they're extremely rare and usually either harmless or instantly caught by the compiler. Still, the mere possibility makes me twitchy.)

gfasdgsfd 12y ago
I'm personally not too happy about this, but there are restrictions on the use of underscores: - You cannot have two underscores in a row - You cannot have a leading underscore
- deleted 12y ago
  [deleted]
def- 12y ago
I would consider it bad style to abuse the case-insensitivity like that. It can be used for good too, for example if you have a bunch of different naming conventions in the libraries you use: proc some_lib_function(x: int) = echo "hi ", x proc anotherLibFunction(x: int) = echo "hi ", x proc crAzY_LIB_WRITERS(x: int) = echo "hi ", x Then you can still call them consistently: someLibFunction(10) anotherLibFunction(11) crazyLibWriters(12)
ebiester 12y ago
Certainly, I would have some sort of lint to enforce naming conventions. I don't like it at all. Searching for a function becomes a nightmare.
- EXetoC 12y ago
  Is it not good enough to have specific grep tools? nimgrep for example, and there are procs for working with this IIRC.
  - def- 12y ago
    I prefer to have a consistent code base, then I can use the internal tools of my editor, which are not aware of Nim's identifier rules.
- zahary 12y ago
  The Nim compiler offers a set of tools intended for use in IDEs ant text-editors that help with this. Besides the style insensitive grep, there are also a compiler-assisted "go to definition" and "list references" commands.
zak_mc_kracken 12y ago
Maybe you're thinking in terms of a text editor and not an IDE? With an IDE, you look for symbol references, not text with regexps. You could imagine that the IDE's search would be smart enough to know that if you look for foo_bar, it should also report occurrences of fooBar. Either way, I still find the idea a bit weird. If the language wants to be opinionated about naming, maybe it could simply make _ illegal in an identifier or, to push it one level further, refuse to compile any identifier that is not camelCase.
- gjm11 12y ago
  I was thinking of both. An IDE is worse unless it's actually targetted specifically at Nim, because its code for finding symbol references surely won't know about Nim's underscore-blindness. (But I'm not much of an IDE-user myself. Perhaps modern IDEs have enough hooks that you really can control this stuff?)
DAddYE 12y ago
The reason of this (while I agree with you) is because Nim comes with a strong interop with C/C++ so the problem is that in C and C++ there is a SnakeCase debate still open. They did that so your program can invoke c (or even nim libs) without taking care of the upcase/underscore style and use your own. While this seems problematic they added some neat features to avoid problems with `uniqueness` of the name and so on. One thing I wish at this point is to force the compiler to stop if this pattern is not uniform within a codebase.

Lrigikithumer 12y ago

I'm pretty sure that was removed, the case insensitivity.

kevin_thibedeau 12y ago

Case-insensitivity is not that much of an issue in static languages. It eliminates the burden of having to remember the Studly-Camel-Lumpy-style-du-jour. Accidental name clashes will be caught at compile time. Nim's hybrid approach is more adventurous but I can only see it being a problem with reusing symbols from other case-sensitive languages.