|
|
|
|
|
|
by alcalde
3208 days ago
|
|
|
Nim's designer is too enamored with Delphi and has chosen to borrow many of Delphi's bad ideas for nostalgic reasons. This adds more ambiguities, more Perl-like symbol use, more reliance on an intelligent IDE, etc. Python is about the importance of simplicity and readability. I don't see Python devs abandoning Python for Nim any time soon. The ones who would have been tempted by Nim have already been tempted away by Go. |
|
|
Presumably you are referring to the way imports are done in Nim, i.e. the fact that all symbols are imported into the current module by default (the equivalent of `from module import *` in Python). Nim could certainly follow Python's lead, but that would limit the language: Nim supports UFCS and operator overloading which requires modules to be imported this way.
You can of course feel free to use `from module import nil` in Nim to enforce module name prefixes for each procedure call. But keep in mind that there is no risk of ambiguities, the compiler statically checks everything and refuses to compile your code if there is an ambiguity (at which point you will need to resolve it by prefixing with the module name).
I would be interested to hear more about other things that you think are a bad idea. Could you elaborate a bit?