# Implicitly loaded modules in the future?

**URL:** <https://discourse.julialang.org/t/implicitly-loaded-modules-in-the-future/62646>\
**Category:** Internals & Design\
**Tags:** question, module, code-organization\
**Created:** [June 9, 2021, 8:58pm UTC](https://discourse.julialang.org/t/implicitly-loaded-modules-in-the-future/62646 "2021-06-09T20:58:00Z")\
**Posts on this page:** 1\
**Showing post:** 25

<div class="post-metadata">

**Author:** ![CameronBieganek](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/cameronbieganek/32/6915_2.png) [@CameronBieganek](https://discourse.julialang.org/u/CameronBieganek)\
**Post date:** [June 10, 2021, 12:44am UTC](https://discourse.julialang.org/t/implicitly-loaded-modules-in-the-future/62646/25 "2021-06-10T00:44:28Z")

</div>

Quoting myself from [this response](https://discourse.julialang.org/t/ann-patmodules-jl-a-better-module-system-for-julia/52226/15) in the above linked thread regarding PatModules.jl:

> One of the reasons that Julia doesn’t use namespaces as aggressively as Python is because we group related functionality into generic functions. Instead of having `List.map` , `String.map` , `Tuple.map` , etc, we just have one generic function `map` . The emphasis is on overloading generic functions rather than putting slightly different versions of functions in separate modules. In order to fully take advantage of multiple dispatch and function overloading, you want a pretty flat namespace.
> 
> (The `List.map` , `String.map` , `Tuple.map` example is taken from languages like Erlang and Elm.)

---

_[View the full topic](https://discourse.julialang.org/t/implicitly-loaded-modules-in-the-future/62646)._