8 ms·

As an admittedly amateur programmer, I think the reasoning is solid. Its difficult to read and understand code that does things like myvalue = myValue. I think

by ac29 7y ago

As an admittedly amateur programmer, I think the reasoning is solid. Its difficult to read and understand code that does things like myvalue = myValue. I think they made the right tradeoff, in that value != Value (the case of the first letter is used), so if you really need to have to values with the same name, you can still do it. As an aside, is there some reason that using the same identifier with different cases is desirable?

SamReidHughes 7y ago
In many languages, you might use one for a type name, the other for a variable. You could ban using the same identifier with different cases, instead of treating them the same.
- blueprint 7y ago
  On the other hand, what if it's a code UI limitation? Suppose the UI for writing Nim had support for linking, editing, viewing all such alternately spelled but equivalent symbols?
  - SamReidHughes 7y ago
    There are tools that aren't nim-specific, like ack/grep/sed/git, and code review tools, which suffer as a result.
  - coldtea 7y ago
    Then it limits me as a programmer to have to use said UI...
- narimiran 7y ago
  > In many languages, you might use one for a type name, the other for a variable. And Nim is one of those languages too. This is perfectly valid and frequently used: type Person = object name: string age: int let person = Person(name: "you", age: 99) echo person You can try it in Nim Playground: https://play.nim-lang.org/#ix=20jS https://play.nim-lang.org/#ix=20jS
bobbylarrybobby 7y ago
Nothing unusual in doing e.g. `array = Array()` (although you should probably give your variables better names than that), which would break in Nim.
- CodeMage 7y ago
  Another perfectly fine example: auto * logger = Logger::getLogger("main");
  - narimiran 7y ago
    ...which also works perfectly fine in Nim.
- ac29 7y ago
  Right, and that's the point, aside from the fact those 2 are actually different in nim. I see what you are doing there, but that would have been very confusing when I started programming. Question is, should the language enforce you giving your variables a better name, or should convention? I think there are reasonable arguments for both.
  - alpaca128 7y ago
    But does a language with Python-like syntax really have to try to be so "beginner-friendly" that it enables inconsistent casing? The language itself can't enforce better variable names, at least not this way - Nim doesn't stop me from using "abcd" or "a0, a1, ... a100" as variable names even though it's usually a very bad idea. No, I think a language should help keeping the code consistent in the long term - and having this strange case insensitivity doesn't help there in my opinion.
    - nimmer 7y ago
      > I think a language should help keeping the code consistent in the long term - and having this strange case insensitivity doesn't help there in my opinion. Not at all. Style insensitivity encourages good variable naming and there are both formatters and also the simple text completion in editors to guarantee consistency.
m45t3r 7y ago
> As an aside, is there some reason that using the same identifier with different cases is desirable? It is mostly for conventions, however different cases are generally used to represent different things. For example, in Python: - ALL_CAPS: global variables - PascalCase: for classes, and now that Python has typing annotations, types - snake_case: everything else, from variables to function/method names (This is not a rule, Python allows anything anywhere, so it is just a convention). So for example, in Nim you couldn't have PERSON (global variable) and Person (class), however you could still have Person (class definition) and person (class instance). Of course, applying the code style from a language to another language is silly, however it is just to illustrate the value of case sensitive identifiers (if you think that my example is more or less valuable than having the flexibility of using a external library the way you want this is your choice). BTW, nowadays I am studying Golang and I found it annoying that you capitalization is meaningful in Go, so person() is a private function however Person() is public. It is generally not bad, however sometimes I want to create a global private constant and can't simple call it MY_CONSTANT since this would make it public.
- Insanity 7y ago
  You get used to the capitalisation. In python the _ prefix threw me off at first as well, but it just kind of grows on you I suppose.
jolmg 7y ago
> As an aside, is there some reason that using the same identifier with different cases is desirable? It's not like that. The thing is that having case insensitive identifiers incentivices people to be inconsistent with their casing "because it doesn't matter" as one coworker that works in a case insensitive language said to me. "Whoops, I wrote 'vALUE'. Well, it doesn't matter; it works. :)" Thank god I don't have to touch that codebase. I do wonder on average how many different variations of casing is used for each variable and keyword.
- beagle3 7y ago
  ... It's like using curly braces to delimit scope incentivizes people to be inconsistent with indentation because "it doesn't matter". Yes, there are always people who would do stupid stuff. But we have decades of experience with Pascal, SQL, VB, VB.Net, Excel and variety of other languages. Decades. They each have their problems, but in wide practice, case [in]sensitivity is not one of them.
  - jolmg 7y ago
    Yet inconsistent indentation is a problem in wide practice. It doesn't take long to find popular open source projects that mix tabs and spaces in their indentation. Of course, many people are going to be consistent with their casing even when using a case insensitive language, but it's nice to know that particular forms of bad style are never going to be an issue because particular rules of good style are enforced by the language.
    - beagle3 7y ago
      Inconsistent indentation is NOT a problem in practice. inconsistent tab/space use is a problem in practice (not a "wide" one in my experience, but not negligible), but if you use the right tab width (and many projects mark it inside the files with a hint e.g. Emacs understands so that won't be an issue) - then it becomes a non problem too. I've never heard of someone saying "I don't care about mixing spaces and tabs because it's the curly braces that matter", and I've never heard of someone who edits a file with inconsistent on-screen indentation and doesn't care.
mehrdadn 7y ago
> Its difficult to read and understand code that does things like myvalue = myValue. I think they made the right tradeoff They could enforce case consistency instead of case insensitivity if that's the problem they're trying to solve, though. Although, even then, consider that variables like 'inform' and 'inForm' might not mean the same thing...
- gjm11 7y ago
  Oh, but that's OK. You can just have inform and in_form. Except you can't because Nim also ignores underscores in identifiers. Gotta make sure there is literally no way to disambiguate cases like this! (I _want_ to like Nim but this single decision seems to me so spectacularly bad that it's a non-starter.)
  - mehrdadn 7y ago
    Sounds like you're agreeing with me?
    - gjm11 7y ago
      Yup. (And saying it's _even worse_ than what you describe.)
  - dom96 7y ago
    You can also just pick a different name, which is something you should probably do anyway in this case.
  - beagle3 7y ago
    I was evangelizing and pushing Python in 1992 (Version 0.9.4) where I worked. The main objection everyone had to even trying ("so spectacularly bad it's a non starter" - think I've heard this wording exactly more than once): Indentation for scoping. I still had to fight that notion in 2010. but thankfully not any more. Now, that does not mean Nim's underscore insensitivity is a good idea, but excuse me for saying "if that's a non starter for you to even trying, I have no respect for your opinion on programming language design". If you actually try and and dislike it, we might be able to discuss merits or opinions. "Ugly" it may be, it is in the eyes of the beholder. But "bad" - what's your metric?
deleted 7y ago
[deleted]
derriz 7y ago
But you’re not fully solving the problem of devs using inappropriate names and you make using popular tools like text editors, grep, ctags, etc more difficult to use effectively. I mean how do you stop devs picking easily confused pairs of identifiers like “xxxxxxxx” and “xxxxxxxx” for example? Feels like a poor design decision to me based on cost/benefit of user ergonomics.
enriquto 7y ago
> As an aside, is there some reason that using the same identifier with different cases is desirable? I do it all the time, in numerical code. If you have two pairs of points, for example, it is very natural to name them "a,A,b,B"
- narimiran 7y ago
  > for example, it is very natural to name them "a,A,b,B" And just to clarify once again, since I'm not sure who will read which reply: those are NOT the same identifiers in Nim! let a = 11 b = 22 A = 99 B = 88 echo a == A # false echo b == B # false Run the code in the Nim Playground if you don't believe: https://play.nim-lang.org/#ix=20kr https://play.nim-lang.org/#ix=20kr
  - enriquto 7y ago
    great! then I don't really understand nim's case insensitivity rules
    - rafaelvasco 7y ago
      Only the first char is case sensitive. The rest is case and underline insensitive;
      - enriquto 7y ago
        Oh, my god! How do people reach this kind of ideas?

by ac29 7y ago

SamReidHughes 7y ago

In many languages, you might use one for a type name, the other for a variable. You could ban using the same identifier with different cases, instead of treating them the same.

blueprint 7y ago
On the other hand, what if it's a code UI limitation? Suppose the UI for writing Nim had support for linking, editing, viewing all such alternately spelled but equivalent symbols?
- SamReidHughes 7y ago
  There are tools that aren't nim-specific, like ack/grep/sed/git, and code review tools, which suffer as a result.
- coldtea 7y ago
  Then it limits me as a programmer to have to use said UI...
narimiran 7y ago
> In many languages, you might use one for a type name, the other for a variable. And Nim is one of those languages too. This is perfectly valid and frequently used: type Person = object name: string age: int let person = Person(name: "you", age: 99) echo person You can try it in Nim Playground: https://play.nim-lang.org/#ix=20jS https://play.nim-lang.org/#ix=20jS

bobbylarrybobby 7y ago

Nothing unusual in doing e.g. `array = Array()` (although you should probably give your variables better names than that), which would break in Nim.

CodeMage 7y ago
Another perfectly fine example: auto * logger = Logger::getLogger("main");
- narimiran 7y ago
  ...which also works perfectly fine in Nim.
ac29 7y ago
Right, and that's the point, aside from the fact those 2 are actually different in nim. I see what you are doing there, but that would have been very confusing when I started programming. Question is, should the language enforce you giving your variables a better name, or should convention? I think there are reasonable arguments for both.
- alpaca128 7y ago
  But does a language with Python-like syntax really have to try to be so "beginner-friendly" that it enables inconsistent casing? The language itself can't enforce better variable names, at least not this way - Nim doesn't stop me from using "abcd" or "a0, a1, ... a100" as variable names even though it's usually a very bad idea. No, I think a language should help keeping the code consistent in the long term - and having this strange case insensitivity doesn't help there in my opinion.
  - nimmer 7y ago
    > I think a language should help keeping the code consistent in the long term - and having this strange case insensitivity doesn't help there in my opinion. Not at all. Style insensitivity encourages good variable naming and there are both formatters and also the simple text completion in editors to guarantee consistency.

m45t3r 7y ago

> As an aside, is there some reason that using the same identifier with different cases is desirable? It is mostly for conventions, however different cases are generally used to represent different things. For example, in Python: - ALL_CAPS: global variables - PascalCase: for classes, and now that Python has typing annotations, types - snake_case: everything else, from variables to function/method names (This is not a rule, Python allows anything anywhere, so it is just a convention). So for example, in Nim you couldn't have PERSON (global variable) and Person (class), however you could still have Person (class definition) and person (class instance). Of course, applying the code style from a language to another language is silly, however it is just to illustrate the value of case sensitive identifiers (if you think that my example is more or less valuable than having the flexibility of using a external library the way you want this is your choice). BTW, nowadays I am studying Golang and I found it annoying that you capitalization is meaningful in Go, so person() is a private function however Person() is public. It is generally not bad, however sometimes I want to create a global private constant and can't simple call it MY_CONSTANT since this would make it public.

Insanity 7y ago
You get used to the capitalisation. In python the _ prefix threw me off at first as well, but it just kind of grows on you I suppose.

jolmg 7y ago

> As an aside, is there some reason that using the same identifier with different cases is desirable? It's not like that. The thing is that having case insensitive identifiers incentivices people to be inconsistent with their casing "because it doesn't matter" as one coworker that works in a case insensitive language said to me. "Whoops, I wrote 'vALUE'. Well, it doesn't matter; it works. :)" Thank god I don't have to touch that codebase. I do wonder on average how many different variations of casing is used for each variable and keyword.

beagle3 7y ago
... It's like using curly braces to delimit scope incentivizes people to be inconsistent with indentation because "it doesn't matter". Yes, there are always people who would do stupid stuff. But we have decades of experience with Pascal, SQL, VB, VB.Net, Excel and variety of other languages. Decades. They each have their problems, but in wide practice, case [in]sensitivity is not one of them.
- jolmg 7y ago
  Yet inconsistent indentation is a problem in wide practice. It doesn't take long to find popular open source projects that mix tabs and spaces in their indentation. Of course, many people are going to be consistent with their casing even when using a case insensitive language, but it's nice to know that particular forms of bad style are never going to be an issue because particular rules of good style are enforced by the language.
  - beagle3 7y ago
    Inconsistent indentation is NOT a problem in practice. inconsistent tab/space use is a problem in practice (not a "wide" one in my experience, but not negligible), but if you use the right tab width (and many projects mark it inside the files with a hint e.g. Emacs understands so that won't be an issue) - then it becomes a non problem too. I've never heard of someone saying "I don't care about mixing spaces and tabs because it's the curly braces that matter", and I've never heard of someone who edits a file with inconsistent on-screen indentation and doesn't care.

mehrdadn 7y ago

> Its difficult to read and understand code that does things like myvalue = myValue. I think they made the right tradeoff They could enforce case consistency instead of case insensitivity if that's the problem they're trying to solve, though. Although, even then, consider that variables like 'inform' and 'inForm' might not mean the same thing...

gjm11 7y ago
Oh, but that's OK. You can just have inform and in_form. Except you can't because Nim also ignores underscores in identifiers. Gotta make sure there is literally no way to disambiguate cases like this! (I _want_ to like Nim but this single decision seems to me so spectacularly bad that it's a non-starter.)
- mehrdadn 7y ago
  Sounds like you're agreeing with me?
  - gjm11 7y ago
    Yup. (And saying it's _even worse_ than what you describe.)
- dom96 7y ago
  You can also just pick a different name, which is something you should probably do anyway in this case.
- beagle3 7y ago
  I was evangelizing and pushing Python in 1992 (Version 0.9.4) where I worked. The main objection everyone had to even trying ("so spectacularly bad it's a non starter" - think I've heard this wording exactly more than once): Indentation for scoping. I still had to fight that notion in 2010. but thankfully not any more. Now, that does not mean Nim's underscore insensitivity is a good idea, but excuse me for saying "if that's a non starter for you to even trying, I have no respect for your opinion on programming language design". If you actually try and and dislike it, we might be able to discuss merits or opinions. "Ugly" it may be, it is in the eyes of the beholder. But "bad" - what's your metric?

deleted 7y ago

[deleted]

derriz 7y ago

But you’re not fully solving the problem of devs using inappropriate names and you make using popular tools like text editors, grep, ctags, etc more difficult to use effectively. I mean how do you stop devs picking easily confused pairs of identifiers like “xxxxxxxx” and “xxxxxxxx” for example? Feels like a poor design decision to me based on cost/benefit of user ergonomics.

enriquto 7y ago

> As an aside, is there some reason that using the same identifier with different cases is desirable? I do it all the time, in numerical code. If you have two pairs of points, for example, it is very natural to name them "a,A,b,B"

narimiran 7y ago
> for example, it is very natural to name them "a,A,b,B" And just to clarify once again, since I'm not sure who will read which reply: those are NOT the same identifiers in Nim! let a = 11 b = 22 A = 99 B = 88 echo a == A # false echo b == B # false Run the code in the Nim Playground if you don't believe: https://play.nim-lang.org/#ix=20kr https://play.nim-lang.org/#ix=20kr
- enriquto 7y ago
  great! then I don't really understand nim's case insensitivity rules
  - rafaelvasco 7y ago
    Only the first char is case sensitive. The rest is case and underline insensitive;
    - enriquto 7y ago
      Oh, my god! How do people reach this kind of ideas?