4 ms·

You touch upon some interesting pain points. I really like Julia and working with it is a pleasure. Except the Module system, which feels unnecessarily arcane.

You touch upon some interesting pain points. I really like Julia and working with it is a pleasure. Except the Module system, which feels unnecessarily arcane. I'm happy to be educated on why, but it seems to successfully combine the awkwardness of C-style #include with the mess of a free-form module system. The end result is a Frankenstein monster where technically everything is possible, everything could be included anywhere, there are no boundaries or even conventions. It makes for a frustrating experience for a newbie. Say you have a package, and inside is a file called `xyz.jl`. You open the file and it defines a module called Xyz. But this tells you absolutely nothing about where in the package Xyz will appear. It could be included somewhere deep in the hierarchy, or it could be a submodule. It could be included multiple times in multiple places! That's bad design for sure, but the language places no boundaries on you. You open another file `abc.jl`, and see no modules at all, just a bunch of functions, which in turn call other functions that are defined God knows where. A julia file does not have to contain any information about where the symbols it's using come from, since it will be just pasted in verbatim to some location somewhere. The whole module system feels like one big spaghetti of spooky action at a distance. It's a shame too, because the rest of the language is very neat. Once one gets over the hurdle of the modules, it is possible to establish conventions to bring some sanity in there, but it's a hurdle that many people will probably not want to deal with.

deleted 7y ago
[deleted]
improbable22 7y ago
How would you like modules to work? It seems great to me that paths & source files are mostly irrelevant, you're free to re-organise without changing anything. And that `using Xyz` is always talking to the package manager. You can make sub-modules and say `using .Xyz`, but there's very little need to do so, and few packages do. You can shoot yourself in the foot by including source twice, as you can by generating it with a macro, or simply copy-pasting wrong.
- Seanny123 7y ago
  I mean, I'd like them to work like Python, Ruby and TypeScript, but you're right to say I can't describe why I want this. Is there some guide I could read about structuring a large Julia project? It was pretty easy to intuit with Python, wherein I would put related files in a folder. But with Julia, everything is everywhere and I'm baffled.
  - short_sells_poo 7y ago
    > But with Julia, everything is everywhere and I'm baffled. This is exactly it. Julia allows you to import and include anything, anywhere. You open a file and it doesn't say anything about where the dependencies are coming from and where this particular piece of code will go. Both of those are defined at the place where this file is included, which itself could be anywhere. It could be a different directory, different file, tucked away in a module. It could be in a dozen other files, or no files at all, and you can't tell from looking at just the source of the file.
    - oxinabox 7y ago
      In practice most packages: 1. Never use submodules (they don't add much) 2. Only use `include` within the main `src/MyPackage.jl` file
  - improbable22 7y ago
    Just reading what everyone does may work. Here's a tiny package: https://github.com/ChrisRackauckas/EllipsisNotation.jl https://github.com/ChrisRackauckas/EllipsisNotation.jl I think that `/src/Name.jl` must have the main module, and `/test/runtests,jl` tests. And the package manager cares about `Project.toml`. But beyond this there are no real rules enforced, although there really seems to be one way to do things. Here's a much bigger project, organised the same way. `include(file.jl)` literally copies in the text, and it's somewhat conventional to collect all imports & exports in the main file: https://github.com/JuliaNLSolvers/Optim.jl/blob/master/src/Optim.jl https://github.com/JuliaNLSolvers/Optim.jl/blob/master/src/O... Still no sub-modules. No files included in mysterious locations. Methods being defined for functions from elsewhere are all qualified, like `Base.show(io::IO, t::OptimizationState) = ...`

deleted 7y ago

[deleted]

improbable22 7y ago

How would you like modules to work? It seems great to me that paths & source files are mostly irrelevant, you're free to re-organise without changing anything. And that `using Xyz` is always talking to the package manager. You can make sub-modules and say `using .Xyz`, but there's very little need to do so, and few packages do. You can shoot yourself in the foot by including source twice, as you can by generating it with a macro, or simply copy-pasting wrong.

Seanny123 7y ago
I mean, I'd like them to work like Python, Ruby and TypeScript, but you're right to say I can't describe why I want this. Is there some guide I could read about structuring a large Julia project? It was pretty easy to intuit with Python, wherein I would put related files in a folder. But with Julia, everything is everywhere and I'm baffled.
- short_sells_poo 7y ago
  > But with Julia, everything is everywhere and I'm baffled. This is exactly it. Julia allows you to import and include anything, anywhere. You open a file and it doesn't say anything about where the dependencies are coming from and where this particular piece of code will go. Both of those are defined at the place where this file is included, which itself could be anywhere. It could be a different directory, different file, tucked away in a module. It could be in a dozen other files, or no files at all, and you can't tell from looking at just the source of the file.
  - oxinabox 7y ago
    In practice most packages: 1. Never use submodules (they don't add much) 2. Only use `include` within the main `src/MyPackage.jl` file
- improbable22 7y ago
  Just reading what everyone does may work. Here's a tiny package: https://github.com/ChrisRackauckas/EllipsisNotation.jl https://github.com/ChrisRackauckas/EllipsisNotation.jl I think that `/src/Name.jl` must have the main module, and `/test/runtests,jl` tests. And the package manager cares about `Project.toml`. But beyond this there are no real rules enforced, although there really seems to be one way to do things. Here's a much bigger project, organised the same way. `include(file.jl)` literally copies in the text, and it's somewhat conventional to collect all imports & exports in the main file: https://github.com/JuliaNLSolvers/Optim.jl/blob/master/src/Optim.jl https://github.com/JuliaNLSolvers/Optim.jl/blob/master/src/O... Still no sub-modules. No files included in mysterious locations. Methods being defined for functions from elsewhere are all qualified, like `Base.show(io::IO, t::OptimizationState) = ...`