That's the last example of a nice design I would bring, and the worst possibly argument in favor of no modules/namespacing.

A flat /usr/bin/... with 1000+ binaries in UNIX is a bad solution we ended up with because back in the day where UNIX was created there were just a few dozens of binaries, so it was "good enough".

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.

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?

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.

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.

I still don't fully agree with it but it makes some things easier. The Windows way also made multiple version installs possible.

And command line tools have that folder added to the PATH, and Windows has a real and ongoing problem with PATH getting too long for the OS to handle when you have enough of them.

Windows is GUI optimized with shell as an afterthought, Linux is vice versa.

It isn't very uncommon to see binaries inside /usr/bin being symlinks to binaries in other directories, even if you stick with distribution-only packages.

NixOS and distri are notable package managers that do make installing different versions of packages pretty easy.

Also i will add that in fact the systen binaries are already split: at minimum /usr/bin and /usr/sbin (but also historically, /bin and /sbin although i think in recent linux system the last two are just symlinks to the formers, or the other way around)

Seriously though, considering the CLI software I use occasionally on my Linux machine, for any given program one - and only one - of the following will tell you its version: -v, -version, --version, version. I never can guess in advance which one is the right to use.

With functions it's worse. In a flat namespace you will inevitably run into a problem of two people coming up with the same name.

IMO python and python3 is a very welcome feature not a negative side effect of no namespaces. At call time it's super explicit so you know exactly what version you're using.

But in most module driven programming languages you might import the foo function at the top of your file and then use foo in 5 different places within that file. However, you spend 99% of your time working with the code in the file not glancing at imports, so now you're left wondering not only where foo is coming from, but who provided foo. Is it from the standard library, your own code base or a third party author? Suddenly you need to keep all of this in your head and it sucks.

Phoenix (a web framework for Elixir) has been taking steps to remove a lot of loose function imports so you know what module they are coming from at call time, but that's because Elixir as a language has modules. But even still, explicitness where you're using it is so much better in the long run for maintenance, even if it involves typing a few more characters.

As always with dynamic things and editing code for them, this will be more difficult to get right when imports are dynamic.

That's a versioning issue, that would happen with namespaces too. You'll have to disambiguate somehow and if a version number is the natural way, then that's the natural way regardless of if a single name or namespaced.

Keeping the next incompatible version as a separate thing (eg python vs python3, instead of continuing python but with semvers saying that 3.0 breaks 2.x compatibility) is actually a good idea. It leads to fragmentation, sure, but it makes dealing with the different versions easier IMHO and incompatible versions may as well be totally different things anyway.

> With functions it's worse. In a flat namespace you will inevitably run into a problem of two people coming up with the same name.

Yes, completely agree!

Microsoft COM would like a word. {20D04FE0-3AEA-1069-A2D8-08002B30309D}

I'm not even sure that reinventing COM would be a bad idea - you can definitely do some great things with it, and the specific implementation details of COM are crufty. But doing so deliberately rather than accidentally would be better, with a review of benefits and problems of COM approaches.

As for the community, maybe not on SV, but there are plenty of Microsoft communities and meeting groups.

https://developer.apple.com/documentation/corefoundation/cfp...

no they don't

I can see it for core libraries, but outside of that I think namespaces are necessary for the greater language ecosystem.

I think the main reason PHP got such a bad rap for flat functions is because they implemented it poorly. So many things were extremely inconsistent when it came to naming conventions and argument orders that it became near impossible to remember them in a systematic way. But couldn't that problem be addressed today since we're aware that naming consistency is an important programming language feature?

> I can see it for core libraries, but outside of that I think namespaces are necessary for the greater language ecosystem.

Yeah I could get on board with that. Docker sort of does this now with Docker images. At the UI level (the tooling we use in our day to day like the CLI) we don't need to access "elixir" or "python" images with a namespace (Docker adds it for us automatically), but we are free to create our own brightball/elixir or nickjj/elixir images to avoid conflicts.

But in a programming world, I would like to type brightball_elixir at call time in my code instead of importing elixir from brightball, because with the latter I have no idea if elixir is coming from you, me, or the standard library unless I move away from the code and look at the import.

That type of stuff. The core language was about the same regardless, but the ecosystem improved dramatically.

To be picky: module and namespace are different concepts.

C++ has namespace and (soon) will have namespaces AND modules.

Namespaces can be seen in C++ as a pure hardcoded prefix for your functions and are a perfectly valid concept with Joe's idea of a "giant KV store for functions".