[akavel]

This topic reminded me of some very interesting thoughts from Joe Armstrong, that I remember seeing posted somewhere (HN?) some time ago -- "Why do we need modules at all?":

    [...]
    The basic idea is
    
        - do away with modules
        - all functions have unique distinct names
        - all functions have (lots of) meta data
        - all functions go into a global (searchable) Key-value database
        - we need letrec
        - contribution to open source can be as simple as
          contributing a single function
        - there are no "open source projects" - only "the open source
          Key-Value database of all functions"
        - Content is peer reviewed
    
    These are discussed in no particular order below:
    [...]

Full thread: http://thread.gmane.org/gmane.comp.lang.erlang.general/53472

[munificent]

> all functions have (lots of) meta data

This is the crux of the problem. Before too long, the amount of metadata dwarfs the thing it describes and it's easier to rewrite the function than it is to find or describe it.

[peterwwillis]

I already deal with a large library of functions like that, and it's totally mind-numbing. I had to create tools just to try to group the functions in different ways so I could figure out if there was anything like what I wanted to use, what it was called, and how to use it.

Modules and sub-module hierarchy offers a greater, simpler organizational methodology.

[TeMPOraL]

I think developers of QuickUtil independently thought of the same and are pursuing this idea.

http://quickutil.org/

[bcoates]

I don't see the difference between this and how module systems in dynamic languages work, the key-value database is accessed with require(), include(), import() or whatever. I suppose you'd need to write a shim to invoke the package manager when an unexpected module is requested but that wouldn't be hard.

[zak_mc_kracken]

> - all functions have unique distinct names

Seriously? Is that his solution to package management?

[TeMPOraL]

Well, if you're using packages and modules, the full name of your function is still packagename/modulename::functionname; it might as well be packagename.modulename.functionname.

Keep in mind that Joe Armstrong is talking about Erlang here, which is a functional language - most of the functions in libraries are sort-of kind-of independent from each other; they especially don't share state.

[xsace]

I can't see how that can be better than a module cohesive API.