An hour and a half ago, Matthias Felleisen wrote:
>> Eli, could you share w/ us why
>> tool/optimization-coach .. with everything in it for this software
> tool/future-visualizer .. with everything in it for this software
>> is a bad idea? Perhaps I am old but I do see a lot of value in a
> deep hierarchical organization. [...]
* One reason is from a simple code organization point of view. I
referred to the unix filesystem convention as an example of this:
- On Windows, every application is in its own directory (there used
to be files in the Windows directory, but they strongly push away
from that)
- On Linux, the Foo application will usually have /usr/bin/foo,
/usr/lib/libfoo, /usr/share/doc/foo, /usr/share/lib/foo,
/usr/share/icons/foo.png, /usr/share/info/foo.info,
/usr/share/man/man1/foo.1 etc etc etc.
- And the new kid on the block inherits a lot of unix-isms, but goes
even further than windows in having the executable itself be a
Foo.app that contains everything it needs...
Now, in our tree we have a little of both -- for example, there are
collects/foo/tests directories in some cases, and collects/tests/foo
in other cases, and scribblings are similarly organized in two ways
too.
I think that the single directory is ultimately easier to deal
with, even when there is a package system that can keep track of
files in different places. There are *many* advantages that you can
get out of it. To name a few:
- It's easy to switch things around so that collects/foo is actually
in its own repository, managed separately from the whole tree (and
I think that getting to that point is absolutely inevitable)
- It's easy to package it up and ship it somewhere -- just zip it,
and send it with instructions for where to unzip it.
- Things like ownership become very easy: you know that if it's in
xrepl/* then you complain to me, and it's easy for me to see when
someone else commits to xrepl so I can look at it.
* Having said that, note that it isn't completely disjoint from using
the directory structure in a way that follow its use -- the only
thing is that the main "package name" comes first, and then a
subdirectory like "tool" or "tests".
*But* -- there is also danger in abusing the directory tree too much
as a replacement for keywords/tags. Say that there's some
"foo/tool/inspector" and later "foo/tool/profiler", what happens
when there's a type inspector -- which keyword "comes first" in the
hierarchy? (Incidentally, the first point makes this question easy
for *me*: it's whatever foo's author wants to do...)
* Finally, there are a few minor exceptions. "typed" can have
subdirectories that are owned by other people, "file"/"net"/"data"
etc are designed to be hosts for very common "keyword-like" uses.
> Perhaps Google will eventually accommodate all these people who
> don't like hierarchical organizations with search tools that find
> everything, including their misplaced car keys, reading glasses, and
> wallets. But we don't have such a tool for finding things in our
> collects/ tree and until we have such a search perhaps we should
> exploit the file system that we do have.
Actually we probably do... I've set up a google code mirror, and they
most likely have tools to search it.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!