4 ms·
I do not recall the exact issue anymore unfortunately, I abandoned the project because of it, but the general sentiment on the Julia discourse seemed to be just
by Datenstrom 8y ago
I do not recall the exact issue anymore unfortunately, I abandoned the project because of it, but the general sentiment on the Julia discourse seemed to be just avoid them. This blog post seems to sum up my issues with modules and namespaces pretty well though:
http://luthaf.fr/julia-some-criticism.html http://luthaf.fr/julia-some-criticism.html
I think that these issues are generally acknowledged although I don't know if they will be addressed. Seems like major pain points for library development should have been addressed before 1.0.
- ChrisRackauckas 8y agoA lot of this blog post is addressed by just using `import` instead of `using`... so it was actually just an issue of not reading the manual. It's like using `from package import *` and then complaining Python doesn't namespace properly.
- masklinn 8y ago> It's like using `from package import <star>` and then complaining Python doesn't namespace properly. It really is not: * `from package import <star>` is more work than `import package`, `using` is shorter than `import` * the official documentation Python documentation starts with qualified imports, then introduces local bindings, and finally unqualified imports, opening a few doc pages imports are either fully qualified or explicitly bound; the first occurrence of using a non-prelude package in Julia's tutorial is `using`[0] and the modules documentation explains `using` first The official Julia documentation very specifically steers the reader towards unqualified imports as the default & proper way to do things, Python's does the opposite. [0] https://docs.julialang.org/en/v1/manual/functions/#Optional-Arguments-1 https://docs.julialang.org/en/v1/manual/functions/#Optional-... edit: oh for fuck's sake I hate hn's shitty brain-dead pseudo-markup.
- ChrisRackauckas 8y agoRight, so this is a documentation thing, and I agree the docs should probably be changed a bit. But it's not a language thing.
- improbable22 8y ago> `using` is shorter than `import` By one letter! And in the right direction: for trying things out interactively, `using ThePackage` and then having everything available is great. Then once you know what you want to do, in more careful code you can switch to `import` and qualify more things, and your future self with thank you. But serving both of these needs seems like a valid design goal. I'm not sure the manual does a great job of explaining this right now, import vs. using also changes the rules around adding methods to functions, and it is perhaps more confusing than it has to be.
- masklinn 8y ago> By one letter! Yes, by one letter. Out of 6. "using" is 16% shorter than "import". And it uses better keyboard alternation (the first 4 letters of `import` are on the right side of a qwerty keyboard, the last 2 on the other, for using the only "i" and "n" are consecutive letters on the same half of the keyboard). So "using" is 1. introduced first 2. the primarily documented import mechanism 3. significantly shorter and 4. significantly more comfortable to type. If Julia's community doesn't want people to use it everywhere, they're doing a very, very good job of fucking with and victimising their users by way over-incentivising the use of `using` over `import`. > And in the right direction: for trying things out interactively, `using ThePackage` and then having everything available is great. And for writing maintainable code it's terrible, despite being by far the easiest and most convenient solution. ChrisRackauckas complains that people use `using` over `import`, literally everything in the language and documentation pushes them towards it. Putting the convenience of interactive sessions way, way over that of proper programs does not seem like "the right direction" to me, especially not when people then jump on their high horses and chide users for doing what the language unambiguously pushes them towards. > But serving both of these needs seems like a valid design goal. Python does that just fine: it provides convenience for interactive use without pushing users towards the least maintainable and desirable option.
- darkpuma 8y ago>Yes, by one letter. Out of 6. "using" is 16% shorter than "import". And it uses better keyboard alternation (the first 4 letters of `import` are on the right side of a qwerty keyboard, the last 2 on the other, for using the only "i" and "n" are consecutive letters on the same half of the keyboard). Counterpoint: I am going to attempt an autocomplete after two characters by pressing tab. Typing 'us' leaves my left hand, the tab hand, as the last used hand before the tab. This prevents me from buffering the tab by moving my hand into position while typing the first two characters. 'im' is typed very easily with my right hand and while I'm typing that, my left hand is free to move into position over the tab key.
- Datenstrom 8y agoAlthough I read the module documentation I did indeed miss that, I was learning mostly from the Julia tutorial notebooks and am definitely a Julia noob. Julia's `using`, `import`, and `include` does seem like it could have a better design. In Rust or Python for example anyone could tell the difference without looking at the docs. I assume `using` was kept for backwards compatibility? I'll need to take another look at the code I was working on. I was planning on doing so after a break anyway.
- agumonkey 8y agofair enough, the article is from 2015 though; these weren't open research problems, I'd hope they've been fixed since.