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.
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?
Thanks!