Hacker News Reader

Comment by rakoo | Hacker News Reader

My personal blocker is that identifiers are all imported globally by convention, so when you see that there is a call to a method called "get", you have to get to the top of the file or mouse over the call to see what lib it is from. A "get" from the http lib is not the same as a "get" from the kv store lib.

View on HN

There is some logic as to why that is. Here [1] is an explanation for why it makes sense but the tldr is that you don't want to be manually importing functions such as `$` and `+`. In languages like Python, those are defined as methods on the object being imported (e.g. `.__str__()`) so they come along for free. Not so in Nim. If there's a conflict (same name, same signature), the compiler will warn you but it's extremely rare.

[1] https://narimiran.github.io/2019/07/01/nim-import.html

Argument-dependent lookup would solve that in a far less global way.

Thank you for the link but it doesn't address the issue I have. It's not about types, or about the compiler being "unsure". It's about me, as a developer, reading code someone else wrote, not knowing directly what package a call is from. I need to leave my current context to have the answer.

I can do `mypackage.mymethod` but it will only be in my own code, because it's not the convention

Ah that makes sense. I agree with you; I’m not a huge fan of trying to infer where the types came from myself either when reading code on GitHub since it doesn’t have the inference that my IDE does.

There are plenty of cases in Python and similar languages where it's not clear where a method is defined, consider `myClassInstance.myMethod`, how do you find its definition? You do not immediately know which class it belongs to, nor where that class is defined. This is especially the case when you've got classes inheriting from multiple levels of other classes.

To put things in context, I don't come from a Python background but from a Go background, where methods are always called with their package (unless it's in the current package). I got used to it because it makes the context clear.

Don't Haskell and Go also do this?

I have no experience in Haskell, but in Go:

- if it's a builtin or in the current package, you usie it directly

- if it's in another package the identifier is always prefixed with the package

Reply on news.ycombinator.com