Hacker News Reader

Comment by aikah | Hacker News Reader

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

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

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.

Reply on news.ycombinator.com