3 ms·

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 d

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.

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.