Hacker News Reader

Comment by zimbatm | Hacker News Reader

Does Nim still allow indifferent `fooBar()` and `foo_bar()` to access the same function call ? It makes grep-powered refactoring unnecessarily hard.

View on HN

Yes, Nim still uses partial case insensitivity: http://nim-lang.org/manual.html#identifier-equality

I agree that it's a problem with grep, there's a nimgrep tool that you could use instead, but I don't.

The nice part about it is that you can use a consitent naming convention even when using external libraries.

My idea to solve the problems this causes without removing it would be a gofmt like tool as described here: https://github.com/Araq/Nim/wiki/GSoC-2015-Ideas#nimfmt-auto...

Is there any way to disable this behavior? I've been curious about Nim, but this makes me cringe pretty hard. I get the intention, but this is exactly the kind of magic that I dislike.

I haven't used go or gofmt, but I don't quite understand the appeal. gofmt doesn't go both ways, right? You can't write go in one style and then gofmt it to share, and then un-gofmt it back to your preferred style, right? Seems like it would still be easiest to just get comfortable writing and reading in the style gofmt produces. At that point, gofmt is just for catching little mistakes, which, maybe the compiler could just do for you. I see python and nim's significant whitespace as a step in that direction. Why not have the compiler/interpreter enforce a certain number of spaces for indentation? Why not enforce a certain naming style?

>Seems like it would still be easiest to just get comfortable writing and reading in the style gofmt produces.

That's the entire point of gofmt. Like many of Go's design choices, it's there to subtly (or not so subtly) encourage doing things in one consistent way.

Oh god, this is so horrible. I've never seen this in the many languages I've used and consider all the programmers happily using those languages without this "feature". Please kill this feature now while the language is still relatively young.

Your comment made me wonder if this feature was conceived as a red herring just to keep people from going on about significant whitespace. :-)

If I ever design a language I might have to remember that.

Ha! Great idea. Significant whitespace is a good thing. "partial case insensitivity"? KIWF! Or at least let it be overridden via configuration flags.

> The nice part about it is that you can use a consitent naming convention even when using external libraries.

I think a slightly nicer (in the sense that it would catch more typos) way to do it might be to specify the naming convention at the top of the source file, and have the compiler enforce that naming convention within the file.

Maybe also have a way to set it in the build system, so it could enforce it for the whole project. That way your project is consistent, but the libraries you rely on don't have to match your conventions.

I was about to say the same thing (about enforcing the convention directly.) But there's a problem. Let's say I write a function called `HTTPHeaderScan()`. Someone else might have used `HttpHeaderScan()`. Or worse: `HtTpHeAdErScAn()`. How do you enforce one over the other? If you said "everthing must be CamelCase," how do you know that the name is wrong?

Assuming you have a consistent naming scheme for your language I'd assume this would be mostly used to call libraries written in other languages

Looks like it's still there in the manual:

http://nim-lang.org/0.11.0/manual.html#lexical-analysis-iden...

This just killed my excitement for this language. That's really surprising to me that they would choose to enforce indentation Python-style, but would then allow this kind ambiguity in naming.

grep and emacs isearch-forward are such great tools for quick code searching and this will break them. I guess text search (and replace) tools could grow nim-mode options, maybe. I don't know, can someone convince me this is a good idea?

> I don't know, can someone convince me this is a good idea?

That would be a pretty hard sell. Any convenience argument falls flat to me.

Suppose you have MyVariable and my_variable in your code. Which is worse: them being the same variable or different variables? It's a pretty bad code smell either way.

In my opinion it should be an error or at least a warning.

I'm not a big fan of nim's behaviour, but I don't think it's any worse than what other languages do.

Yeah, I think it would make more sense to treat them as the same, but throw an error if they are spelled differently.

"Which is worse: them being the same variable or different variables?"

Them being the same is worse. I agree that both are pretty darn bad, but it's also pretty clear to me which is worse.

> Suppose you have MyVariable and my_variable in your code. Which is worse: them being the same variable or different variables?

That's the same as saying "`a` and `A` should be the same variable", i.e. complete case insensitivity.

> It's a pretty bad code smell either way.

Very much so. We shouldn't encourage it.

> Suppose you have MyVariable and my_variable in your code. Which is worse: them being the same variable or different variables?

Having them be the same, by far.

Having names with certain similarity be prohibited in the same scope is a bit excessively controlling but sensible. Allowing them but treating them as equivalent is just plain bad. If I named them differently then either: (1) I made a mistake, or (2) I intended them to be different.

Huh? This is terrible.

I use same names with different styles to denote scope. I will be hosed then.

This is my least favorite "feature" of Nim as well and almost killed my interest in it. But it hasn't come up in practice yet for me.

> grep and emacs isearch-forward are such great tools for quick code searching and this will break them.

If you're using Emacs to begin with... well there is little reason to complain about the default behaviour of functions and keybindings.

Sure, but I don't use emacs exclusively (as often as that joke is leveled at emacs users, nobody really does that).

You must not use grep with regexes very often.

Are you serious? Quick, write me a grep regexp that will catch all equivalently valid forms of a nim_Identifier (or nimidentifier or nImID_entif_iEr, but not NimIdentifier).

Not really, sorry. I had forgotten that the first letter is compared case sensitively as I remembered from Nimrod it was all insensitive. But I still think for nearly all cases in real world code you can instead of using nimgrep be equally served by a case insensitive search on (nimidentifier|nim_identifier) even if it's technically possible to have other variants or a mismatch, which you can grep out as a second step anyway, with the capital N.

This feature makes very little sense to me. What's the justification for this?

Developer convenience. Some people like Hungarian notation, some like underscores. I consider it quite convenient as well. Probably there is a need for a tool for source code normalization so that everyone can choose his favorite notation in the whole Nim ecosystem.

I wouldn't consider the loss of identifier recognition a "convenience". This would be a major concern for my adopting the language.

You also have to read others' code, as well...

Safety! Having "my_cat" and "myCat" as different variables in the same space sometimes ends up with using the wrong variable, especially when using tab completion.

The feature is not meant to encourage developers to use "my_cat" and "myCat" randomly within the same file.

I don't like the idea of a language encouraging sloppy coding.

This is not different than having foo_bar and foo_Bar as two different variables.

Well, yes, it is.

And its worse, especially when the variables aren't "foo_bar" and "foo_Bar", but, say, "cycle_often" and "cycle_of_ten".

> "cycle_often" and "cycle_of_ten".

Such an error is caught by the compiler.

  const cycle_often = 10
  var cycle_of_ten : float

  ambig.nim:2:5: Error: redefinition of 'cycle_of_ten'

"The feature is not meant to encourage developers to use 'my_cat' and 'myCat' randomly within the same file."

I'm sure it's not, but it isn't doing a thing to discourage that. We stopped using case insensitive file systems a long time ago, didn't we?

...actually we didn't.

> We stopped using case insensitive file systems a long time ago, didn't we?

Windows didn't.

But even Windows doesn't use an underscore-insensitive file system.

I'd rather have them be different identifiers but with a compiler warning if they're found in the same file.

Safety might prohibit different identifiers with a certain degree of similarity, but it wouldn't treat different-but-similar identifiers as if they were the same.

Treating them as the same creates more danger -- the danger that the programmer intended them to be different, but the language treated them the same -- rather than mitigating danger.

Sometimes the best name for a variable is a variation of the associated class/function name.

For example: http://blog.codinghorror.com/the-case-for-case-insensitivity...

This doesn't make any sense. When I make a mistake in case, Rust just doesn't let me compile.

You get this problem when you have two identifiers (variables, functions, constants, etc.) that differ only in case and have the same type signature. Depending on whether you use one or the other form, you may get completely different behavior.

The convention is that upper case is types, lower case is variables. So you'd have to try hard to make that mistake.

That has nothing to do with types vs. variables.

Try having a variable signon and a variable signOn. Or two functions with the same type signature, one called signon() and one signOn() (for example, imported from two different modules).

By default, the Rust compiler warns you when you use uppercase characters in variable and function identifiers. The community overwhelmingly adheres to this style. Rust is also extremely strongly-typed, so not only would you have to be willfully disabling the style warnings, you would have to have to manage to give them the same types, and furthermore given the nature of Rust code it's rather possible that you'll still get a compilation error due to using a variable in a way that it didn't expect. You also can't "accidentally" introduce new variables in Rust, as you can in Python via typos.

Yes, enforcing case strictly via style guidelines that prevent mixing of upper- and lowercase is another way of avoiding that problem (underscores can still trip you up in a similar fashion, of course, e.g. signon vs. sign_on). I'm still not sure how the discussion got sidetracked into discussing Rust, though.

> I'm still not sure how the discussion got sidetracked into discussing Rust, though.

Yes, let's generalize - reading the blog and the comments, this "case sensitivity ruins productivity"-problem seems to only be a problem in scripting languages.

You'd have to declare both of them in the current module. That's why I don't do glob imports.

I would see

    use foo::signon;
    use bar::signOn;

clearly, if I have to import this in my own file I should be VERY careful about those two functions

or rather, I'd import from foo, but I'd use the namespaced version from bar

so `signon` would be `foo::signon`, but `bar::signOn` would be written out fully to avoid this kind of clash

I'm really not sure what the point of referencing Rust is. This was about programming languages in general, and the post I was referring to was about C#. Also, importing is an example, another example would be accidentally declaring a second variable in the same module (should not happen, but people make errors), or a number of other situations where two identifiers that are identical except for case end up in the same scope.

I'm referencing Rust because I'm working on a Rust project right now. I don't even know C#.

Here's how you declare a binding:

    let signOn;
    let signon;

I seriously hope you don't declare both of these in the same scope

Why not just recommend one way of naming things and do it in all standard APIs? If someone obviates in his custom library, that's his problem. I think below are pretty much a standard in many languages now.

THIS_IS_A_CONSTANT SomeClass someVariable someMethod()

Reply on news.ycombinator.com