Implicitly loaded modules in the future?

[PetrKryslUCSD]

@mhinsch

Of course, as usual, none of this would be necessary if we assumed a perfect genius programmer, but then that perfect genius programmer wouldn’t need Julia but could just write in assembly. In a way most of what happened in applied computer science since the 50s or so is developing cognitive crutches for imperfect humans.

I think the genius programmer will be more productive in a high level language. Computers are good at writing assembly; people are good at writing high level language code, whether they be genius or not. The genius programmer is then distinguished by being able to descend to the level of assembly code when needed (read: when such optimization pays off).

[fkjogu]

@CameronBieganek

An import statement like from A import foo implies that everything I need to know about foo can be found in A , but it’s just not true—not even close to being true.

Hey, can you elaborate this statement, please? In a world, where you would have to explicitly import every version of foo, wouldn’t you know exactly what where to lookup the information concerning foo?

So basically, if you have to declare something along

from A import foo
from B import foo

you would be guaranteed that the dispatcher only uses A.foo and B.foo and nothing else, wouldn’t it?

I think the appeal of having explicit namespacing and importing is that you have control over the interactions. If everything lives in one gigantic namespace, I find it harder to trace every occurrence of a method (yes, tooling can help here, however it is no guarantee). Especially in a foreign code base that could be suprising, couldn’t it?