Hacker News Reader

Comment by tenfingers | Hacker News Reader

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.

View on HN

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.)

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

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)

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.

Is it not good enough to have specific grep tools? nimgrep for example, and there are procs for working with this IIRC.

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.

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.

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.

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?)

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.

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.

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

Reply on news.ycombinator.com