6 ms·

I cant think of a single situation in which I would want take_action() and Take_Action() to do different things inside of a program. What reasonable purpose wou

I cant think of a single situation in which I would want take_action() and Take_Action() to do different things inside of a program. What reasonable purpose would naming things that way serve? I see it as a mandated style checker built into the language.

IshKebab 4y ago
Nobody wants codebases with different take_action() and Take_Action() functions. That's a straw man. The issues are: 1. Difficult to search code. Even just case insensitivity makes this worse because often you do have names that only differ in case (but in an acceptable way, e.g. they're different kinds of thing, or namespaces). But ignoring underscores makes it much much harder - now every search needs to be a regex. You can say "use an IDE!" and you absolutely should but you still sometimes need to search with dumb grep style tools. 2. Case insensitive rules are always more complex and difficult to remember. Where do they apply? All identifiers or just variables? What about keywords. Nim's rule is especially complex. It adds cognitive load. 3. Extra bike shedding. I imagine they added it to avoid bike shedding? But it will have the opposite effect. They should have just made a language wide convention like Rust. Nobody debates case style in Rust or indentation style in Go because the tooling and community pretty much force one style. I fully anticipate a Nim linter that bans style variation from the canonical one. If that doesn't exist already.
- xigoi 4y ago
  > They should have just made a language wide convention like Rust. I don't know about Rust, but Python has a language-wide convention – and programs still violate it, including the standard library.
  - runarberg 4y ago
    In JavaScript (the wild west of programing languages) when I see a library that exports names in non-idiomatic ways, or otherwise has a non-idiomatic API, I usually search for a different library.
    - xigoi 4y ago
      The DOM API, which is objectively the most important JavaScript library, has an inconsistent naming convention. Specifically, it can't decide whether it wants to treat acronyms/initialisms as words. See for example getElementById versus innerHTML.
      - runarberg 4y ago
        I do like Array.prototype.includes vs. Element.classList.contains also which APIs use promises vs. callbacks vs. events. Like I said, JavaScript is the grandmaster of mixing and mashing idioms.
  - IshKebab 4y ago
    Very rarely though in my experience.
- otherme123 4y ago
  It doesn't seen like a strawman when in Python you are forced to write like this: import logging import sys sys.breakpointhook() sys.exc_info() logging.getLogger(__name__) And both `sys` and `logging` are not obscure builtins, they are used everywhere. And just for that, case is not fixable.
  - deleted 4y ago
    [deleted]
  - IshKebab 4y ago
    Is there also a `get_logger()` or `excInfo()`? I don't think so.
    - xigoi 4y ago
      Why does that matter?
      - IshKebab 4y ago
        Because the original comment was about two similarly named but different functions. Otherme123's example didn't have that.
- Manabu-eo 4y ago
  1 - Every search? What nightmarish code base are you imagining? That paranoia is not based on experience. 2 - Negligible cognitive load in my experience. You can just ignore that part of the language and treat it as case sensitive and everything will work. Inside projects it's effectively case sensitive too. And the rules just make sense, they are just there to allow you to be consistent in your casing, nothing less nothing more. It applies everywhere they are need for that, and nowhere else. 3. Gofmt wasn't a thing when Nim(rod) started and now is too late to force all projects to a single style. But projects are internally consistent, and you can always use your preferred style, so I consider Nim's a superior solution. > I fully anticipate a Nim linter that bans style variation from the canonical one. If that doesn't exist already. The compiler already warns you by default if you are not consistent on the spelling of identifiers inside your code, and you can make that an error too. See `--styleCheck:usages` and `--styleCheck:off|hint|error`. There is a nim linter that can make your code conform to NEP-1, but last time I saw it was a bit too buggy in that style transformation, so people don't usually use it. I've been programming for years in Nim and never had any problem grepping or searching for things because the style insensitivity. In pratice it's a non-problem.
000ooo000 4y ago
IMHO from a theory POV, it violates the/my principle of least surprise. Compilers are typically strict and I'm ok with that - my mental models of programing are built around that unforgivingness and I like it, because if I play by the rules, I know there'll be no surprises (ideally). When the rules are relaxed, I have to remember more stuff. It's easier for me to know that ABC is ABC, and never abc or a_b_c. I think I remember reading early remarks from the Nim team that you can opt-in to the symbol sensitivity but it's a marker comment per-file, or some kind of DIY preprocessor which does the same. I'd be happy if it was a CLI switch. All that said, and in practice, clearly a lot of people are fine with this and even like it. I'd much rather Nim exist with this (IMO) oddity than not at all.

IshKebab 4y ago

Nobody wants codebases with different take_action() and Take_Action() functions. That's a straw man. The issues are: 1. Difficult to search code. Even just case insensitivity makes this worse because often you do have names that only differ in case (but in an acceptable way, e.g. they're different kinds of thing, or namespaces). But ignoring underscores makes it much much harder - now every search needs to be a regex. You can say "use an IDE!" and you absolutely should but you still sometimes need to search with dumb grep style tools. 2. Case insensitive rules are always more complex and difficult to remember. Where do they apply? All identifiers or just variables? What about keywords. Nim's rule is especially complex. It adds cognitive load. 3. Extra bike shedding. I imagine they added it to avoid bike shedding? But it will have the opposite effect. They should have just made a language wide convention like Rust. Nobody debates case style in Rust or indentation style in Go because the tooling and community pretty much force one style. I fully anticipate a Nim linter that bans style variation from the canonical one. If that doesn't exist already.

xigoi 4y ago
> They should have just made a language wide convention like Rust. I don't know about Rust, but Python has a language-wide convention – and programs still violate it, including the standard library.
- runarberg 4y ago
  In JavaScript (the wild west of programing languages) when I see a library that exports names in non-idiomatic ways, or otherwise has a non-idiomatic API, I usually search for a different library.
  - xigoi 4y ago
    The DOM API, which is objectively the most important JavaScript library, has an inconsistent naming convention. Specifically, it can't decide whether it wants to treat acronyms/initialisms as words. See for example getElementById versus innerHTML.
    - runarberg 4y ago
      I do like Array.prototype.includes vs. Element.classList.contains also which APIs use promises vs. callbacks vs. events. Like I said, JavaScript is the grandmaster of mixing and mashing idioms.
- IshKebab 4y ago
  Very rarely though in my experience.
otherme123 4y ago
It doesn't seen like a strawman when in Python you are forced to write like this: import logging import sys sys.breakpointhook() sys.exc_info() logging.getLogger(__name__) And both `sys` and `logging` are not obscure builtins, they are used everywhere. And just for that, case is not fixable.
- deleted 4y ago
  [deleted]
- IshKebab 4y ago
  Is there also a `get_logger()` or `excInfo()`? I don't think so.
  - xigoi 4y ago
    Why does that matter?
    - IshKebab 4y ago
      Because the original comment was about two similarly named but different functions. Otherme123's example didn't have that.
Manabu-eo 4y ago
1 - Every search? What nightmarish code base are you imagining? That paranoia is not based on experience. 2 - Negligible cognitive load in my experience. You can just ignore that part of the language and treat it as case sensitive and everything will work. Inside projects it's effectively case sensitive too. And the rules just make sense, they are just there to allow you to be consistent in your casing, nothing less nothing more. It applies everywhere they are need for that, and nowhere else. 3. Gofmt wasn't a thing when Nim(rod) started and now is too late to force all projects to a single style. But projects are internally consistent, and you can always use your preferred style, so I consider Nim's a superior solution. > I fully anticipate a Nim linter that bans style variation from the canonical one. If that doesn't exist already. The compiler already warns you by default if you are not consistent on the spelling of identifiers inside your code, and you can make that an error too. See `--styleCheck:usages` and `--styleCheck:off|hint|error`. There is a nim linter that can make your code conform to NEP-1, but last time I saw it was a bit too buggy in that style transformation, so people don't usually use it. I've been programming for years in Nim and never had any problem grepping or searching for things because the style insensitivity. In pratice it's a non-problem.

000ooo000 4y ago

IMHO from a theory POV, it violates the/my principle of least surprise. Compilers are typically strict and I'm ok with that - my mental models of programing are built around that unforgivingness and I like it, because if I play by the rules, I know there'll be no surprises (ideally). When the rules are relaxed, I have to remember more stuff. It's easier for me to know that ABC is ABC, and never abc or a_b_c. I think I remember reading early remarks from the Nim team that you can opt-in to the symbol sensitivity but it's a marker comment per-file, or some kind of DIY preprocessor which does the same. I'd be happy if it was a CLI switch. All that said, and in practice, clearly a lot of people are fine with this and even like it. I'd much rather Nim exist with this (IMO) oddity than not at all.