3 ms·
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.
by 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 agoI've never had a namespace collision problem. Not when reusing or when importing. When was the last time you used Nim?
- lqdc13 11y agoYesterday. 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 agoComing 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 agoHaving 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.