4 ms·

The deal breaker for me is the variable name normalization: userName == user_name == username == uS_eR_aN_mE It used to be totally case insensitive now it is

The deal breaker for me is the variable name normalization: userName == user_name == username == uS_eR_aN_mE It used to be totally case insensitive now it is case sensitive for the first letter. Underscores are ignored: two identifiers are considered equal if the following algorithm returns true: proc sameIdentifier(a, b: string): bool = a[0] == b[0] and a.replace(re"_|–", "").toLower == b.replace(re"_|–", "").toLower For me it is a capital violation of the "principle of least astonishment".

Mikeb85 11y ago
Because it's such a deal breaker that you can't have "userName" and "user_name" in the same scope. This was brought up in the other thread, and it's just as silly now. Rejecting an absurd naming scheme is a feature.
- dom96 11y ago
  For those who would like to read the previous thread: https://news.ycombinator.com/item?id=10931800 https://news.ycombinator.com/item?id=10931800
3pt14159 11y ago
I actually love this. It makes it easy to write code in either a JS context (where you want camel case) or Ruby(ish) context. I really don't see how this is a deal breaker. It's one of the first things you learn when you start with Nim and I've never had a problem with it. To me this is kinda akin to the people that complain about the magic in Rails or that Ruby includes so many things by default (like rand or sleep) without working on a couple of projects first. Those really aren't the problems that slow you down in Ruby and this isn't really something that is an issue in practice.
- lqdc13 11y ago
  it's a huge problem because in many cases you have no idea that you are reusing a variable, because in every other language you wouldn't be reusing a variable. This plus the crazy global name space pollution. If you import something, everything is imported from that module. I have no idea what to name things because everything collides with everything else. In Python, things are simple. Classes are 'CapitalCase' and functions are 'lower_case'. If I did the same thing in nim, they would collide. Also, in Python it is considered a terrible idea to do from some_module import * in Nim, it is the way things are done. Although, they are alternative methods that don't do this. also, the weird var a, b = 0 Perhaps you get used to it with time. But still namespace collision is always a problem for me especially when working with others' libs. However, it is currently the most painless way to write fast code and integrate with Python, which says a lot. Edit: Looks like first letter matters now, so ignore that part of the comment.
  - 3pt14159 11y ago
    I've never had a namespace collision problem. Not when reusing or when importing. When was the last time you used Nim?
    - lqdc13 11y ago
      Yesterday. But I ran into the issue last week. I was reusing "paramStr" variable. This is a built in in the os module. I defined "param_str" in my module. Then wrote another module that was using the first one. Then realized I was overwriting an OS module function. I actually have no idea how such collisions are handled. What if I import another module that overwrites the OS module? What if a 3rd party lib uses some variable that another 3rd party lib also defined? A whole set of problems would be gone if such importing was looked down upon. I mean it is exactly the same situation in Python (but not exacerbated by the name canonicalization), and people realized a long time ago that doing this is not a good idea.
      - robochat42 11y ago
        Coming from python, I'm also surprised by the way Nim imports but I realised that it's not the same sitution because nim uses unified function call (ufc) syntax to implement its method calls. Methods are functions that due to the UFC sugar can be used as methods and so everything needs to be imported from a module in order that methods are visible to the calling scope. This works better than you might expect since the correct function normally gets called due to static typing. Of course this doesn't fix variable name collisions. I'd need to program more in nim though to decide how much of a problem this is.
        robochat42 11y ago
        Having looked at the tutorial, I can see now that variable name collisions (i.e. if defined in two imported modules) are caught as errors by the compiler. Also only deliberately exposed symbols get imported into the namespace which reduces the namespace overlap considerably.
- cma 11y ago
  It destroys the ability to search. You have to use a crazy regex to search for all instances of a variable.
david-given 11y ago
Urgh. I wish languages wouldn't do this. Things which look different should be different. At least it's case sensitive for the first letter, which means that the traditional lowercase-for-identifiers, capitalised-for-types naming scheme works. I've tried programming in Ada, which has case insensitive identifiers; it was deeply painful. Edit: Plus, of course, case sensitivity is locale dependent. Are I and i the same letter? Not if you're Turkish. (Upper case i is İ; lower case I is ı.) Yes, this matters. http://www.theinquirer.net/inquirer/news/1017243/cellphone-localisation-glitch http://www.theinquirer.net/inquirer/news/1017243/cellphone-l...
- dom96 11y ago
  I would be interested to hear your experiences with Ada, what in particular made case insensitive identifiers painful. Can you give some examples?
- throwaway999888 11y ago
  So uppercase Turkish `ı` is the same as ASCII `I`?. Go and Haskell also have some special (unconventional) treatment of capital letters, which probably make them biased towards the English language.
  - lifthrasiir 11y ago
    Yes. And uppercase Turkish `i` (which is same to ASCII `i`) is not ASCII `I` but Turkish `İ`. Obviously this behavior is very locale-specific. > Go and Haskell also have some special (unconventional) treatment of capital letters, which probably make them biased towards the English language. In Ruby an identifier is considered to start with an uppercase letter when it really starts with an uppercase letter or underscore; that probably is the best compromise for unicase scripts including CJK scripts.
    - throwaway999888 11y ago
      It's a weird language bug. I wish English (and my own tongue) was as consistent with the dots as Turkish is. ;)

Mikeb85 11y ago

Because it's such a deal breaker that you can't have "userName" and "user_name" in the same scope. This was brought up in the other thread, and it's just as silly now. Rejecting an absurd naming scheme is a feature.

dom96 11y ago
For those who would like to read the previous thread: https://news.ycombinator.com/item?id=10931800 https://news.ycombinator.com/item?id=10931800

3pt14159 11y ago

I actually love this. It makes it easy to write code in either a JS context (where you want camel case) or Ruby(ish) context. I really don't see how this is a deal breaker. It's one of the first things you learn when you start with Nim and I've never had a problem with it. To me this is kinda akin to the people that complain about the magic in Rails or that Ruby includes so many things by default (like rand or sleep) without working on a couple of projects first. Those really aren't the problems that slow you down in Ruby and this isn't really something that is an issue in practice.

lqdc13 11y ago
it's a huge problem because in many cases you have no idea that you are reusing a variable, because in every other language you wouldn't be reusing a variable. This plus the crazy global name space pollution. If you import something, everything is imported from that module. I have no idea what to name things because everything collides with everything else. In Python, things are simple. Classes are 'CapitalCase' and functions are 'lower_case'. If I did the same thing in nim, they would collide. Also, in Python it is considered a terrible idea to do from some_module import * in Nim, it is the way things are done. Although, they are alternative methods that don't do this. also, the weird var a, b = 0 Perhaps you get used to it with time. But still namespace collision is always a problem for me especially when working with others' libs. However, it is currently the most painless way to write fast code and integrate with Python, which says a lot. Edit: Looks like first letter matters now, so ignore that part of the comment.
- 3pt14159 11y ago
  I've never had a namespace collision problem. Not when reusing or when importing. When was the last time you used Nim?
  - lqdc13 11y ago
    Yesterday. But I ran into the issue last week. I was reusing "paramStr" variable. This is a built in in the os module. I defined "param_str" in my module. Then wrote another module that was using the first one. Then realized I was overwriting an OS module function. I actually have no idea how such collisions are handled. What if I import another module that overwrites the OS module? What if a 3rd party lib uses some variable that another 3rd party lib also defined? A whole set of problems would be gone if such importing was looked down upon. I mean it is exactly the same situation in Python (but not exacerbated by the name canonicalization), and people realized a long time ago that doing this is not a good idea.
    - robochat42 11y ago
      Coming from python, I'm also surprised by the way Nim imports but I realised that it's not the same sitution because nim uses unified function call (ufc) syntax to implement its method calls. Methods are functions that due to the UFC sugar can be used as methods and so everything needs to be imported from a module in order that methods are visible to the calling scope. This works better than you might expect since the correct function normally gets called due to static typing. Of course this doesn't fix variable name collisions. I'd need to program more in nim though to decide how much of a problem this is.
      - robochat42 11y ago
        Having looked at the tutorial, I can see now that variable name collisions (i.e. if defined in two imported modules) are caught as errors by the compiler. Also only deliberately exposed symbols get imported into the namespace which reduces the namespace overlap considerably.
cma 11y ago
It destroys the ability to search. You have to use a crazy regex to search for all instances of a variable.

david-given 11y ago

Urgh. I wish languages wouldn't do this. Things which look different should be different. At least it's case sensitive for the first letter, which means that the traditional lowercase-for-identifiers, capitalised-for-types naming scheme works. I've tried programming in Ada, which has case insensitive identifiers; it was deeply painful. Edit: Plus, of course, case sensitivity is locale dependent. Are I and i the same letter? Not if you're Turkish. (Upper case i is İ; lower case I is ı.) Yes, this matters. http://www.theinquirer.net/inquirer/news/1017243/cellphone-localisation-glitch http://www.theinquirer.net/inquirer/news/1017243/cellphone-l...

dom96 11y ago
I would be interested to hear your experiences with Ada, what in particular made case insensitive identifiers painful. Can you give some examples?
throwaway999888 11y ago
So uppercase Turkish `ı` is the same as ASCII `I`?. Go and Haskell also have some special (unconventional) treatment of capital letters, which probably make them biased towards the English language.
- lifthrasiir 11y ago
  Yes. And uppercase Turkish `i` (which is same to ASCII `i`) is not ASCII `I` but Turkish `İ`. Obviously this behavior is very locale-specific. > Go and Haskell also have some special (unconventional) treatment of capital letters, which probably make them biased towards the English language. In Ruby an identifier is considered to start with an uppercase letter when it really starts with an uppercase letter or underscore; that probably is the best compromise for unicase scripts including CJK scripts.
  - throwaway999888 11y ago
    It's a weird language bug. I wish English (and my own tongue) was as consistent with the dots as Turkish is. ;)