Author here. For my part, I have never understood why people consider it to be a good thing to squirrel code into a bunch of different sub-directories.
a) It makes the build scripts more complicated, which means they'll be more likely to break on some poor noob, and that when they break it'll be less likely the noob will be able to tell how to fix it.
b) Invariably the codebase accumulates dependencies between directories that are uneconomic to reorganize. At least a flat directory has a shot at under-promising and over-delivering.
c) Maybe people do it to make the place look neat, they way I used to 'clean my room' by stuffing all my dirty clothes into drawers. But codebases that are messes at a deep level are less likely to be cleaned up if they look clean at a superficial level. And all codebases eventually turn into messes, the way we've done things so far.
Sure, directories can be used badly (and the Java and Ruby projects I've seen are often very difficult to navigate because so much is the structure of the language, rather than the structure of the project).
But they can also be used well, and the promise of a meaningful directory structure is really appealing.
Here's a question, given all of what I understand about your layered way of structuring code: how easy is it to spin off logical portions of a project? If my project accretes its own HTTP server and I want to turn that into a stand alone library, could I? Would it be possible to "rewrite history" so that the HTTP-related changes never appeared in the layers to start with?
Yeah, that's a good question. Even though the mu core is at the top directory, there are a couple of apps in sub-directories of their own. To run a single-file mu program you say:
$ ./mu factorial.mu
To run a more complex app, you just give a directory name rather than a filename:
$ ./mu edit
Files inside the directory are loaded in numeric order just like at the top level. You can also run just a subset of the layers for the editor:
$ ./mu test edit/001*
$ ./mu test edit/00[12]*
$ ./mu test edit/00[1-3]*
(Notice how the number of tests/dots grows at each layer.)
Since the layers are just regular files there's nothing stopping you from rewriting history as much as you want. That ability was precisely what I built them for.
I've only recently started using directories, so I'm sure there's stuff here I haven't considered. Feedback most welcome.
I think the reason why people (I put myself into this camp as well) prefer directories for organization is because there is an entire ecosystem built around them. Backing up, recursive search, exploring via ui, programmable access, programmatic access using language of ones choice are all choices available to the user. Code organization isnt the only place this shows up, organizing music and photos has similar semantics - apps which try to do the organization via higher level metadata rarely put in the engineering effort to come up with robust solutions for all the above use cases I cited abode.
It's not the same. I can open, process, or skim a directory containing a thousand files without much trouble or CPU activity. Having a thousand files worth of information in one file means I have to run through all that data at once. This has implications in data integrity as well if I'm making changes or worried about bitrot.
So, no, there's a difference. I'll also note that Daniel Bernstein of qmail & NaCl often used a filesystem how some use databases under the philosophy of "Why create new, complex functionality when you have well-tested code that gets the job done?"
I have to admit, I like long files. Arc's compiler is all in one file (https://github.com/arclanguage/anarki/blob/master/ac.scm) and it was a big influence on me. It was just so great to be able to have it open on one side while I wrote programs in Arc.
You're right that there are points beyond which a single file becomes too unwieldy, but with a good editor that limit is quite high for me. Maybe 10k LoC. Directories can grow even larger before they start having problems.
a) It makes the build scripts more complicated, which means they'll be more likely to break on some poor noob, and that when they break it'll be less likely the noob will be able to tell how to fix it.
b) Invariably the codebase accumulates dependencies between directories that are uneconomic to reorganize. At least a flat directory has a shot at under-promising and over-delivering.
c) Maybe people do it to make the place look neat, they way I used to 'clean my room' by stuffing all my dirty clothes into drawers. But codebases that are messes at a deep level are less likely to be cleaned up if they look clean at a superficial level. And all codebases eventually turn into messes, the way we've done things so far.