6 ms·

Significant whitespace and case- and underscore insensitivity. That's pushing too many of my buttons for one language. That being said, this is a very well wri

Significant whitespace and case- and underscore insensitivity. That's pushing too many of my buttons for one language. That being said, this is a very well written tutorial. Might be a nice format to use in other basic language tutorials.

ivoras 8y ago
For example, what do you think of Go? It's case-sensitive and whitespace-insensitive, but almost everyone formats their code with gofmt, which next to eliminates "creativity" with whitespace, letter case and braces (but makes the code uniform and readable across authors).
deleted 8y ago
[deleted]
gameswithgo 8y ago
it isn't entirely case insensitive, just to clarify.
- jessaustin 8y ago
  If anything this clarification makes Nim seem less appealing. I hope Nim has a very good reason to make its case sensitivity "case-dependent", because it sounds quite confusing...
  - dom96 8y ago
    The first character of an identifier is case sensitive and by convention used to determine whether the identifier is a type or not. As for style insensitivity: it allows you to keep your code base consistent. Ever had to use a library that used snake_case in your own camelCase codebase? Well, with Nim you can just use camelCase everywhere.
    - kungtotte 8y ago
      I also don't see the issue with it. You can have a uniform style in your project, regardless of dependencies you use. And what's the flipside? People want to use more than one identifier named the same thing only with different case? Is that really desirable? I posit that if you have a codebase that breaks if fooBar and foobar refer to the same variable, it's already broken!
      - jjnoakes 8y ago
        The flip side is one has to use a Nim-specific search tool to find occurrences of an identifier.
        dom96 8y ago
        In practice you really don't. As kungtotte alluded to, no one is going to be mixing coding conventions inside a single code base. As soon as you see the first identifier is camelCase you can safely assume that the rest of them are also camelCase, and therefore search using camelCase.
        beagle3 8y ago
        I'd say that's only mostly true - if you had a typo, and wrote "camelcase" instead of "camelCase" in just one place out of a hundred, you might not notice it, but it will compile, and not match a grep (though it will match nimgrep). This case could be solved by "grep -i" or equivalent, but not the camelcase vs. camel_case case. This is not criticism; I prefer Nim's mostly-case-and-underscore-insensitive approach, but I think this is a pitfall that should be acknowledged and taken into account (which is quite easy to do given the included nimgrep). Perhaps it makes sense to have an optional warning in case a name is inconsistently spelled inside the same compilation unit.
        nimmer 8y ago
        > if you had a typo, and wrote "camelcase" instead of "camelCase" in just one place out of a hundred There are already formatter tools that check for that. Also, any editor with completion will suggest the right form every time preventing the bug.
narimiran 8y ago
> this is a very well written tutorial. Might be a nice format to use in other basic language tutorials. Author of the tutorial here. Thank you very much for your kind words! > Significant whitespace and case- and underscore insensitivity. That's pushing too many of my buttons for one language. Coming from Python, I had no problem with the significant whitespace. I like it more than curly braces everywhere. Case- and underscore- insensitivity were something I initially really didn't like. What were they thinking? Are they out of their minds? After using Nim for a year, I must say I didn't experience any problem with it so far. All the code I have written, all the code from others I have read uses camelCase (which is a recommended, but not enforced, case). So basically, even though people have an option to use snake_case (or any other), the large majority of users use only the one style.
audunw 8y ago
> Case- and underscore insensitivity This is a great feature when interfacing directly with C libraries. You can declare the names as they are in the original library, which is best for debugging and reference. They can be a variety of styles, but in your code you can refer to them all with camelCase so you have a consistent style in your own code. I've never had any problem with it. It just works, and if you don't want to use it, it's not going to be an issue.

ivoras 8y ago

For example, what do you think of Go? It's case-sensitive and whitespace-insensitive, but almost everyone formats their code with gofmt, which next to eliminates "creativity" with whitespace, letter case and braces (but makes the code uniform and readable across authors).

deleted 8y ago

[deleted]

gameswithgo 8y ago

it isn't entirely case insensitive, just to clarify.

jessaustin 8y ago
If anything this clarification makes Nim seem less appealing. I hope Nim has a very good reason to make its case sensitivity "case-dependent", because it sounds quite confusing...
- dom96 8y ago
  The first character of an identifier is case sensitive and by convention used to determine whether the identifier is a type or not. As for style insensitivity: it allows you to keep your code base consistent. Ever had to use a library that used snake_case in your own camelCase codebase? Well, with Nim you can just use camelCase everywhere.
  - kungtotte 8y ago
    I also don't see the issue with it. You can have a uniform style in your project, regardless of dependencies you use. And what's the flipside? People want to use more than one identifier named the same thing only with different case? Is that really desirable? I posit that if you have a codebase that breaks if fooBar and foobar refer to the same variable, it's already broken!
    - jjnoakes 8y ago
      The flip side is one has to use a Nim-specific search tool to find occurrences of an identifier.
      - dom96 8y ago
        In practice you really don't. As kungtotte alluded to, no one is going to be mixing coding conventions inside a single code base. As soon as you see the first identifier is camelCase you can safely assume that the rest of them are also camelCase, and therefore search using camelCase.
        beagle3 8y ago
        I'd say that's only mostly true - if you had a typo, and wrote "camelcase" instead of "camelCase" in just one place out of a hundred, you might not notice it, but it will compile, and not match a grep (though it will match nimgrep). This case could be solved by "grep -i" or equivalent, but not the camelcase vs. camel_case case. This is not criticism; I prefer Nim's mostly-case-and-underscore-insensitive approach, but I think this is a pitfall that should be acknowledged and taken into account (which is quite easy to do given the included nimgrep). Perhaps it makes sense to have an optional warning in case a name is inconsistently spelled inside the same compilation unit.
        nimmer 8y ago
        > if you had a typo, and wrote "camelcase" instead of "camelCase" in just one place out of a hundred There are already formatter tools that check for that. Also, any editor with completion will suggest the right form every time preventing the bug.

narimiran 8y ago

> this is a very well written tutorial. Might be a nice format to use in other basic language tutorials. Author of the tutorial here. Thank you very much for your kind words! > Significant whitespace and case- and underscore insensitivity. That's pushing too many of my buttons for one language. Coming from Python, I had no problem with the significant whitespace. I like it more than curly braces everywhere. Case- and underscore- insensitivity were something I initially really didn't like. What were they thinking? Are they out of their minds? After using Nim for a year, I must say I didn't experience any problem with it so far. All the code I have written, all the code from others I have read uses camelCase (which is a recommended, but not enforced, case). So basically, even though people have an option to use snake_case (or any other), the large majority of users use only the one style.

audunw 8y ago

> Case- and underscore insensitivity This is a great feature when interfacing directly with C libraries. You can declare the names as they are in the original library, which is best for debugging and reference. They can be a variety of styles, but in your code you can refer to them all with camelCase so you have a consistent style in your own code. I've never had any problem with it. It just works, and if you don't want to use it, it's not going to be an issue.