What's actually wrong with it though? Why isn't it still "good enough"? It's hard to read the list, but Linux has plenty of tools to fix that particular problem. I don't really see the issue.
Name clauses.
Version clauses. "All binaries inside a folder" needs renames to allow for a different version (even if it's a different minor version).
It's just the binaries, which was OK back in the "program = single binary", before "man" even, days, but now it splits the program from different assets it uses (man pages, default configuration, image assets, etc). This in turn makes deleting/moving more difficult, and adds all kinds of baggage to package managers.
>It's hard to read the list, but Linux has plenty of tools to fix that particular problem.
That's a description of the problem to me. Needing "plenty of tools" to fix an initial bad commitment.
https://zolk3ri.name/cgit/zpkg/
It seems very minimal but supports my requirements. It makes sense to me, because everything gets installed (usually via make install) to ~/.local/pkg/foo-1.0/ and the like, and then symlinks are created to, say, ~/.local/{bin,etc,include,lib,man,share,var}. According to the source code, it is configurable via environment variables. It seems to share similarities with GNU's stow.
I see it as easier to discover.
Imagine if you had to goto /usr/bin/output/user to find the whoami binary.
If you did, who is responsible for making those directories and what happens when you have a binary that could really belong in 5 different places?
The other issue is that the approach is extremely inflexible, if you want to replace /usr/bin/program with a new version, everybody on the system is forced to use the new version, even if the new version might break stuff. Traditional `/usr/bin` doesn't provide a solution for this. You can of course work around that by using `/opt` or installing things in your home directory, but at that point you are just using the file system as namespace.
i think the solution to this problem (module or not) will be the same solution to the shared lib problem.
npm is a dumpster fire, but the larger projects are usually fine (the /bin equivalent). the worst problem is that every large project pull in different versions of whatever libs they wanted to use (which the singleton util lib proposed in the article would solve)
Anyone who has had to try to manage security permissions on a big flat list of files knows it's like holding jello with rubber bands.
As an another example people might be familiar with: having to manage a big PHP or Ruby codebase where everything is separated by the models, views, and controllers a hierarchical level _above_ the business function. It's a nightmare. Trying to pull out the useful business functionality that's interleaved everywhere makes it very hard to pull codebases apart to where different teams can work on them.
With respect to Joe's comment here:
> Bad: It's very difficult to decide which module to put an individual function in. Break encapsulation (see later)
As much as I like Joe's thought process, that "difficult" part is otherwise known as "the real work". All systems which scale in complexity--as opposed to the simple problem scaled in performance--need strong boundaries. They also all have a hierarchical component to them.