3 ms·

A 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 `f

A 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 ago
  Right, 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.
    - improbable22 8y ago
      But you have to type `python3` which is 7 letters to 5, if we're counting :) Seriously though, it's hard to write one manual which gives everyone the perfect on-ramp for their needs. I actually think it's fair to aim it low, make it easy for matlab refugees to get started, interactively. People who know how namespacing works in several other languages (and intend to write big projects) are the ones well-equipped to know how to dig deeper. Nobody has been victimised!
Datenstrom 8y ago
Although 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.

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 ago
Right, 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.
  - improbable22 8y ago
    But you have to type `python3` which is 7 letters to 5, if we're counting :) Seriously though, it's hard to write one manual which gives everyone the perfect on-ramp for their needs. I actually think it's fair to aim it low, make it easy for matlab refugees to get started, interactively. People who know how namespacing works in several other languages (and intend to write big projects) are the ones well-equipped to know how to dig deeper. Nobody has been victimised!

Datenstrom 8y ago

Although 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.