As I understand it, Nim's development has always been done with tooling in mind.

This has some wonderful advantages: uniform function call syntax, awesome IDE 
support built-in, unobtrusive syntax, convenient import system, etc. All of 
these would not be possible without proper tooling in the first place and it is 
a delight to code in Nim in vim with all these.

But at the same time, I am a bit worried the lack of namespaces (or any other 
strong form of encapsulation, **by default**). Let me insist on that last 
point: Nim **can** be as encapsulated as I would wish it to be, but the 
majority of the code out there just import Foo.

How is that a problem? In two specific cases:

  * When you write code, you feel necessary **not to** use "common names" for 
your procedures: if I have a module dedicated to reading one kind of files, I 
would avoid using read/open/parse/etc. because the probability that 
read(string) is already imported somewhere is pretty high. The solution? 
Prefixing or more-explicit-but-far-less-obvious naming. This is exactly what's 
happening in Julia (which shares a lot of concepts with Nim) and the result is 
not nice: package writers change the names because package users cannot be 
bothered by the compiler saying they must use full name resolution for that 
specific function OR import it as something else themselves. From my 
perspective, I don't want to ever worry about some implementation details 
clashing with other unrelated packages: that's what namespaces are for.
  * When you read code, you always need a full-fledged IDE. I am not arguing 
that Nim should be conveniently writable without an IDE... certainly not! 
However, I would like to be able to quickly be able to get an idea of what is 
coming from where when looking at a package on github instead of using a 
full-sized computer with a properly configured IDE each time I dare reading 
code. Not that it would work every time (that's what IDE support built in the 
compiler is for!) but at least it would give some useful hints. This is not a 
fundamental problem (i.e. there is an existing solution: proper tools) but 
doing this in Python, this is really convenient when skimming through a package.



That said, I am not for explicit import by default either: I think we may find 
some way to keep the convenience of the current system while improving on the 
two points above. What do you think?

Reply via email to